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CHAPTER  1 
INTRODUCTION 

1.1  Objective  of  Research 

1 

The  ultimate  objective  of  the  research  reported  in 
this  report  is  the  automation  of  the  programming  j 

task  for  automatic  test  systems. 

This  task  is  presently  carried  out  by  individuals  i 

..  1 

who  combine  the  skills  of  engineering  and  computer  pro-  ] 

i 

gramminj^.,  and  who  generally  employ  an  ad  hoc  approach. 

•Thi's  task  is  laborious  and  frequently  tiresome,  which  5 

accounts  for  both  the  high  costs  involved  and  low  ^ ’ • 

conf idence  ...in  the  resulting  products.  The  resulting 
low  re  l.iab  ili  ty  ;of  electronic  and  automotive  equipment 
has  had  far-r each ing  • ee onom ic  and  societal  effects. 

The. first  step  towards  automation  of  the  test 
programming  task  has  been  the  structuring  o f a . . 

respective  methodology.  For  example,  a typical  analog 
electronic  circuit  test  programming  process  can  be 
summarized  as  follows: 

(1)  Obtain  circuit  diagram,  manuals,  and  other 
design  documents. 

(2)  Input  the  circuit  to  a circuit  simulator,  e.g.,  ; 

ECAP  (Electronic  Circuit  Analysis  Programs). 

(3)  Simulate  failure  mode  of  components  of  interest,  ! 

and  determine  failure  symptom. 

J 


1 


(4) 


Evaluate  potential  tests  that  would  have  . . 
corresponding  symptom  in  case  Qf  confponent 
failure.  ^ 

(5)  Prepare  a flowchart  for  efficient  conduct  of 
test. 

(6)  Code  test  program..  ■ 

(7)  Debug  the/test.  program.'- 

Note  that  a tesjt  engine.^r,  who  mu;st  also  be  a computer 
pr ogrammer , is  reispons ib le  for  carrying  out  this  whole 
pro c^ss ' manua,lly'. /■  Jhus -.'ain  . exper  t is  absolutely  needed 
,to.«  detep-iiidivie  arid'  Specify  tests.  Moreover  he  must  spend 
a considerable  .amount  of  time  in  coding  and  debugging 
the  . t.e-s.t  program..  The  top  aad  bottom  parts  of  the  ATS 
software  comporient  as  depicted  in  Figure  1.1  are  aimed 
at  automating  these  various  test  steps,  hence  eliminating 
or  reducing  the  above-mentioned  problems. 

1.2  Overview  Of  An  Automatic  Test  System 

In  order  to  define  the  objectives  more  precisely 
it  is  necessary  to  digress  very  briefly  and  review  the 
testing  processes  in  the  life  of  a product. 

An  Automatic  Test  System  (ATS)  consists  of  several 
elements  such  as  the  data  base,  circuit  simulation,  test 
generation,  test  language,  and  automatic  test  equipment 
[TO  74].  However,  an  ATS  can  be  considered  to  be  composed 
of  two  components:  (1)  hardware  which  consists  of  the 
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computer-controlled  automatic  test  equipment  (ATE)  and 
(2)  software  which  deals  with  the  design  and  programming 
of  tests.  This  view  of  ATS  and  its  interactions  with 
the  unit  under  test  (UUT)  are  illustrated  in  Figure  1.1. 
As  indicated  at  the  right-hand  side  of  the  figure,  the 
software  component  is  further  divided  into  two  parts: 

(1)  top  part  which  determines  test  specifications 
[TIN  77]  and  (2)  bottom  part  which  analyzes  and  sequences 
an  input  test  specification  and  generates  an  efficient 
test  program  for  an  automatic  test  equipment.  The  link 
between  these  two  parts  is  a non-procedural  test 
specification  language  called  NOPAL,  in  which  the  test 
specifications  are  described. 

A model  of  ATS  at  test-time  including  the  inter- 
actions among  its  various  components  is  illustrated 
in  Figure  1.2.  The  operator  gets  access  to  the  UUT 
through  control  keys,  dials,  or  meters.  The  ATE 
includes  a new  architecture  in  which  programmable  stimuli 
and  measurement  devices  can  be  connected  to  the  UUT 
connecting  points  under  the  control  of  a programmable 
interface  unit  (PIU) . The  PIU  can  also  connect  the 
programmable  power  supply  and  impedance  (not  shown  in 
the  figure).  The  general  purpose  computer  (1)  controls 
the  PIU  switches,  (2)  sets  those  programmable  units  to 


ATE-UUT 

INTERFACE 


perform  the  corresponding  functions,  (3)  performs  fault 
diagnosis  based  on  measurement  results,  and  (4) 
communicates  with  the  operator  by  sending  messages  to 
and  receiving  responses  from  the  operator’s  console. 

Note  that  the  system  described  in  this  dissertation 
would  also  be  applicable  to  conventional  ATEs , where 
stimuli  generators  and  meters  are  pooled  and  shared 
among  connecting  pins. 

1.3  Intermediate  Goals  Of  The  Research 

The  intermediate  goals  of  this  dissertation  research 
have  been  to: 

(1)  develop  a string-form,  free-format,  non-proce- 
dural test  specification  language,  NOPAL,  in  which  a 
test  engineer  can  easily  describe  a test  specification 
of  a UUT , or  in  which  the  automated  top  part  of  Figure 
1.1  can  effectively  specify  a complete  set  of  tests  to 
meet  testing  objectives; 

(2)  design  and  Implement  a software  system,  called 
NOPAL  Processor,  which  takes  as  input  a test  specifica- 
tion described  in  NOPAL,  performs  syntax  and  semantics 
analysis,  sequences  and  optimizes  the  tests,  and  finally 
generates,  an  efficient  program  in  a procedural  test 
language,  OPAL; 

(3)  Interface  with  the  user  through  messages  and 
documentation  to  facilitate  specification  preparation 
and  program  maintenance. 
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effectively.  A complete  test  specification  in  NOPAL 
provides  the  information  on  the  three  major  components 
of  an  ATS  (as  shown  in  Figure  1.2)  at  test  time:  (1) 

a set  of  test  modules,  (2)  the  UUT,  and  (3)  the  ATE. 

The  UUT  specification  describes  (1)  the  UUT  connect- 
ing points  which  can  be  connected  to  ATE  through  inter- 
face and  (2)  the  potential  UUT  component  failures. 

The  ATE  section  specifies  (1)  the  ATE  inter-connect- 
ing points  which  can  be  connected  to  matching  UUT  points 
and  (2)  all  types  of  ATE  functions:  stimuli,  measure- 
ment, failure,  and  evaluation  which  are  referenced  in 
the  test  modules. 

A test  module  specification  consists  of  (1)  stimuli 
to  be  applied  (2)  measurements  to  be  performed  (3)  logic 
to  select  the  diagnoses,  (4)  operator  message  of  each 
diagnosis,  and  (5)  operator  response  of  each  diagnosis. 

Instead  of  string  form  a NOPAL  test  specification 
can  also  be  described  in  tabular  form  as  presented  in  an 
earlier  report  [PRY  75,  in  which  this  author  took  part]. 
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NOPAL  is  presented  in  Chapter  3 in  more  detail. 

Several  features  of  this  language  are  extremely 
important  in  providing  the  ease  and  interactive  features 
which  are  necessary  for  effective  use. 

First,  it  is  non-procedural.  The  user  can  save 
much  labor  as  compared  to  the  use  of  procedural  languages 
because  he  need  not  specify  the  execution  order  of  events 
or  the  control  logic.  Nor  does  he  need  to  specify  storage 
declarations.  These  procedural  actions  will  be  deduced 
by  the  processor.  All  the  statements  are  descriptive  as 
opposed  to  imperative,  and  they  can  be  entered  in  any 
order.  The  specification  of  each  test  in  a multi  test 
specification  can  be  independently  prepared.  This 
independence  of  statements  or  test  modules  enables  the 
user  to  concentrate  on  composing  a single  entity  at  a 
time.  Also  the  test  modules  can  be  modified  or  added 
incrementally  without  considering  the  effect  on  other 
tests.  Thus,  virtually  no  computer  programming  knowledge 
is  needed. 

Second,  NOPAL  has  the  capability  of  self  document- 
ation. Various  reports  such  as  reformatted  specifica- 
tion listing,  cross  references,  error  messages,  and 
sequencing  flowcharts  are  available  to  the  user.  This 
documentation  will  enhance  the  user-system  interaction 
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or  pinpoint  erroneous  spots  in  the  user's  specification. 

Third,  the  NOPAL  language  and  its  processor  are 
independent  of  both  the  units  under  test  and  the  object 
automatic  test  equipments.  Consequently  NOPAL  can  be 
utilized  to  specify  various  classes  of  UUTs,  such  as 
hydraulic  and  mechanical,  in  addition  to  electronic 
devices.  Of  course,  the  simulation  process  (i.e.  top 
part  of  Figure  1.1)  must  be  re-designed  for  different 
classes  of  UUTs.  Any  changes  in  the  ATE  configuration 
have  no  effects  on  the  NOPAL  methodology.  In  this  case, 
only  the  ATE  functions  (which  are  procedures  defined  in 
the  object  test  language)  should  be  properly  modified  if 
another  set  of  ATE  is  to  be  used. 

NOPAL  is  well-structured  from  top  down.  A test 
specification  is  functionally  grouped  into  three  sections: 
ATE,  UUT , and  test-modules.  Each  test  module  is  then 
divided  into  three  subsections:  stimuli,  measurement, 
and  logic  to  select  diagnoses.  Finally  a stimulus  or 
measurement  section  is  further  broken  into  two  distinct 
parts:  (1)  conjunction  which  involves  UUT  connection  and 

ATE  waveforms  functions,  and  (2)  assertions  which  perform 
pure  computations.  This  simple  structure  enables  the 
user  to  master  the  language  easily.  On  the  other  hand, 
due  to  nopal's  non-proceduralness  and  incr emen t a 1 i t y , 
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test  modules  can  be  composed  independently  from  bottom 
up  by  a single  user  or  a group  of  co-workers.  Also,  a 
user  is  relieved  of  the  burden  of  explicitly  specifying 
the  execution  sequence  of  test  modules  and  the  storage 
assignments,  hence  he  can  concentrate  on  what  needs  to 
be  done  rather  than  on  how  to  do  it.  As  a whole,  the 
NOPAL  methodology  should  enhance  new  understanding  of 
programming  process,  and  exemplify  the  top-down 
structured  programming  and  team  management  techniques 
[MIL  71 , BAK  72 , STE  74]  . 

The  intuition  and  often  unorganized  thinking  of 
the  human  being  have  been  transformed  into  precise  and 
systematic  algorithms.  For  instance,  based  on  the 
knowledge  of  how  the  test  engineer  sequences  his  test 
steps,  several  sequencing  strategies  such  as  data 
dependency  and  top-down  fault  isolation  have  been  intro- 
duced. In  addition  some  new  algorithms  have  been 
developed.  For  example,  a cycle  enumeration  and  elimin- 
ation algorithm  is  used  in  the  phase  of  graph  analysis, 
and  several  algorithms  for  invoking  test  module  routines 
and  inserting  proper  control  logic  are  used  in  code- 
generation phase. 

1.5  Importance  and  Contributions  of  the  Research 

The  importance  of  this  research  is  manifold.  First, 
it  affects  real  life  --  it  saves  money.  The  research 


will  enhance  an  ATS  in  achieving  the  goal  of  reducing 
the  enormous  amount  of  maintenance  and  support  costs 
on  various  complex  systems,  especially  electronics 
systems.  Currently,  the  cost  ratio  of  computer  software 
to  hardware  exceeds  2:1,  and  it  has  been  forecast  to 
approach  10:1  in  ten  years  [e.g.  BOE  74,  PRY  74].  Thus 
any  means  of  reducing  the  cost  of  software  production 
in  general  is  highly  in  demand.  Particularly,  the  costs 
in  maintenance  and  support  of  electronics  systems  are 
soaring,  primarily  as  a result  of  systems  complexity. 

For  example,  in  1973  the  U.S.  Department  of  Defense 
spent  $15.7  billion  on  electronics,  more  than  a third 
($5.4  billion)  of  this  amount  were  spent  on  maintenance 
and  support.  It  has  been  estimated  that  80%  of  main- 
tenance goes  to  labor,  and  that  about  87%  of  the  repair 
time  is  required  to  locate  and  isolate  defective  com- 
ponents. Therefore  the  use  of  an  ATS,  which  deals  with 
diagnosis  and  fault  isolation,  can  be  estimated  to  affect 
almost  70%  of  the  total  maintenance  cost. 

This  research  also  has  its  intellectual  importance. 
Automatic  testing  is  a complex  and  laborious  task. 

Various  aspects  of  the  total  ATS,  such  as  UUT  and  its 
de s i gn/ f ab r i ca t i on /main t enanc e life  cycle,  the  functions 
of  ATE,  the  role  of  an  operator,  and  test  determination 
need  to  be  understood.  The  current  exclusive  role  of 
human  being  in  specifying  and  programming  test  procedures 
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should  be  replaced  by  an  automation  process.  Thereby 
considerable  amount  of  time  and  effort  spent  in  pro- 
gramming and  debugging  can  be  saved.  The  expertise  to 
play  a dual  role  as  engineer  and  programmer  is  no  • 

longer  needed.  Human  errors  will  be  much  reduced.  The 
understanding  of  a complex  system  and  the  transformation 
of  the  intuitive  tasks  into  precise,  concrete  algorithms 
are  important  and  significant  in  computer  science  in 
general. 

The  major  contribution  of  this  research  is  the 
development  of  a non-procedural  test  specification 
language  NOPAL  and  the  design  and  implementation  of  a 

software  generation  system  (NOPAL  Processor)  which  | 

I 

automatically  produces  reliable  test  programs  from  | 

specifications  in  NOPAL.  j 

The  specification  language  is  intended  to  be  used  j 

easily  by  engineers  to  describe  tests  of  UUTs  manually,  | 

j 

or  by  the  automatic  test  determination  process  to  specify  | 

tests  systematically.  Based  on  the  test  specification, 

the  Processor  will  perform  analysis  on  syntax  and 

semantics,  check  f or  ‘comp  1 et ene ss  and  consistency, 

optimize  execution  sequence  of  test  modules,  and  generate 

a complete  test  program.  Therefore  this  system  is  | 

expected  to  help  reduce  the  amount  of  labor  and  necessary  j 
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expertise,  program  preparation  and  debugging  times, 
human  errors,  etc.,  and  ultimately  help  cut  the 
enormous  maintenance  costs. 

In  summary,  the  NOPAL  system  is  designed  to 
eliminate  the  dual  role  of  being  an  application  pro- 
grammer and  the  test  engineer  and  provides  a direct 
communication  between  the  test  engineer  (or  the 
automatic  test  determination  process)  and  the  ATE.  It 
is  a crucial  step  in  the  total  automation  of  test 
determination  and  test  program  generation,  hence  has 
potential  savings  of  manpower  and  costs  needed  for 
systems  maintenance  and  support. 

1.6  Organization  of  the  Report 

Chapter  2 summarizes  the  background  and  motivation 
of  this  research.  Also  included  is  a survey  of  related 
literature  and  research. 

Chapter  3 is  a user  manual  for  the  NOPAL  language. 

It  briefly  presents  the  OPAL  object  language.  The  formal 
syntax  of  NOPAL  and  the  overall  structure  of  OPAL  are 
also  provided  in  an  extended  BNF  notation. 

Chapter  4 gives  an  overview  of  the  NOPAL  processor, 
the  automatic  test  program  generation  system.  It 
summarizes  the  three  major  phases  of  the  Processor:  (1) 

syntax  analysis,  (2)  specification  analysis,  design,  and 
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sequencing,  and  (3)  code  generation. 

Chapter  5 describes  the  first  phase  of  the  NOPAL 
Processor.  It  presents  in  detail  the  syntax  and  state- 
ment analysis  of  the  NOPAL  specification,  and  the 
simulated  associative  memory  where  the  specifications 
are  to  be  stored.  Included  also  are  a meta-language 
EBNF/WSC,  a me t a -p r oc e s s or  SAPG,  and  a formal  syntax 
of  NOPAL  in  EBNF/WSC. 

Chapter  6 covers  the  second  phase  of  the  NOPAL 
Processor  - specification  analysis,  design  and  sequenc- 
ing. It  includes  the  theoretical  background,  methodology 
and  the  algorithms  of  the  intra  and  inter  test-module 
analysis  and  sequencing. 

Chapter  7 presents  the  last  phase  of  the  Processor, 
code  generation.  At  this  phase  the  analyzed  and  sequenced 
test  specification  is  encoded  into  a complete  test  pro- 
gram in  an  object  language,  in  particular,  OPAL. 

Algorithms  and  data  structures  needed  in  this  code- 
generation phase  are  outlined. 

Chapter  8 summarizes  the  conclusions  that  can  be 
drawn  from  this  research,  and  suggests  future  research 
areas. 

At  the  end,  an  appendix  is  provided  with  a list 
of  data  structures  used  in  the  NOPAL  system,  and  a 
sample  NOPAL  test  specification  together  with  its 
corresponding  output  which  has  been  produced  by  the 
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CHAPTER  2 


SURVEY  OF  RELATED  LITERATURE  AND  RESEARCH 

2.1  Introduce  ion 

As  already  indicated,  this  research  has  been 
primarily  motivated  by  two  considerations.  First  was 
the  concern  over  Che  soaring  costs  of  software  develop- 
ment. This  consideration  is  shared  by  research  on 
automatic  programming.  For  example,  it  is  believed  that 
the  entire  software  development  process  could  be  automated 
effectively.  Section  2.2  summarizes  the  research  on 
automation  of  software  development  in  various  applications. 

The  second  consideration  concerned  particularly 
the  widespread  need  for  test  programs  utilizing  a rapidly 
advancing  technology  of  automatic  test  systems  (ATS). 
Section  2.3  surveys  automatic  testing  generally  and 
Section  2.4  presents  some  typical  programming  languages 
for  automatic  test  equipments. 

As  will  be  shown,  while  there  has  been  great 
progress  in  facilitating  software  development  through 
automation,  the  application  of  such  techniques  in  auto- 
matic testing  is  lagging  considerably  behind  their  use 
in  other  areas.  The  progress  in  automatic  testing  has 
been  impressive  in  new  hardware  techniques,  but  the  soft- 
ware state-of-the-art  in  automatic  testing  has  not 
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experienced  similar  progress.  One  of  the  objectives  of 
the  research  reported  here  has  been  to  correct  this 
unbalance . 

2.2  Research  on  Automation  of  Software  Development 
Process 

Recently  there  has  been  a concerted  effort  to 
automate  software  development  process  systematically. 
Typically,  this  process  can  be  broken  into  several  phases 
as  outlined  below  [TEI  71,  COU  73,  PRY  74]. 

(1)  Determination  of  problem  requirements 

(2)  Functional  specifications  of  the  system 

(3)  Physical  design  of  the  system,  including  system 
module  decomposition  and  input/output  speci- 
fications 

(4)  Program  design 

(5)  Program  implementation:  coding,  debugging, 
and  documentation 

(6)  System  integration  and  installation 

(7)  Operation,  maintenance,  and  modification 
Although  some  progress  has  been  made  on  the  automation 

of  the  first  two  phases,  the  interest  here  is  in  research 
on  the  automation  of  the  remaining  phases.  This  is 


summarized  below. 


Early  theoretical  work  to  develop  design  techniques 
includes  an  information  algebra  [COD  62],  a machine- 
independent  problem-defining  language  for  systems  analysts. 
Langefors  [LAN  63]  also  introduced  some  theoretical 
approaches  to  information  systems. 

Although  the  evolution  of  computer  software  techni- 
ques has  always  lagged  that  of  computer  hardware  [COU  73], 
many  automation  facilities  such  as  assemblers,  compilers 
and  operating  systems  have  been  developed  to  help  reduce 
human  laborious  effort  and  errors.  In  addition  there 
have  been  important  developments  to  aid  system  specifi- 
cation and  documentation.  Several  manual  techniques 
such  as  SOP  [IBM  61]  and  ADS  [LYN  69]  have  been  designed 
for  this  purpose.  Later  some  of  these  languages  were 
supported  by  automation.  For  example,  ADS  processors 
[THA  71]  were  developed  but  were  not  used  extensively. 

IBM's  TAG  system  (Time  Automated  Grid)  was  developed  in 
1962  and  automated  later  [IBM  71].  Another  language 
useful  to  systems  analysts  in  designing  information 
models  was  systematics  [GRI  66]. 

Developed  at  the  University  of  Michigan  were  a 
problem  statement  language  (PSL)  for  describing  system 
requirements  and  a problem  statement  analyzer  (PSA)  to 
analyze  and  produce  program  specifications  [TEI  71, 

TEI  74,  TEI  76].  Nunamaker  extended  PSL/PSA  into 
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SODA  (Systems  Optimization  and  Design  Algorithm),  whose 
objective  was  to  generate  a complete  system  design  from 
a statement  of  the  processing  requirements  [NUN  71]. 

The  use  of  computer-aided  analysis  for  the  design  and 
development  of  an  integrated  financial  management  system 
using  SODA  and  ADS  was  exemplified  in  [NUN  76]. 

Research  on  automatic  program  generation  has  been 
pursued  for  years  at  the  University  of  Pennsylvania. 

In  1973,  a DDL/DML  system  was  developed  to  automate  the 
generation  of  data  conversion  programs  [RAM  73].  Since 
then  the  research  effort  has  been  directed  to  the 
development  of  two  automatic  program  generation  systems; 
NOPAL  and  MODEL. 

The  NOPAL  system,  which  is  the  topic  of  this 
d is se r t at  ion,  was  introduced  to  achieve  the  goal  of 
total  automation  of  test  determination  and  test  program 
generation  for  computer-controlled  automatic  test  equip- 
ments [PRY  75].  The  system  consists  of  two  independent 
parts:  (1)  top  part  --  test  determination  of  electronic 

circuits  and  (2)  bottom  part  --  automatic  test  program 
production.  The  top  part  determines  complete  test 
specifications  expressed  in  the  NOPAL  language  [TIN  77]. 
The  bottom  part,  described  in  this  dissertation  accepts 
as  input  the  test  specifications  written  in  the  NOPAL 
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language  and  produces  as  output  an  efficient  test  pro- 
gram in  a procedural  test  programming  language  OPAL, 

The  bottom  part  can  also  accept  test  specifications 
manually  prepared  by  a user. 

A MODEL  system  was  developed  in  1974-5.  It 
generates  PL/1  programs  for  business  applications  of 
transaction  processing  [RIN  76].  A revised  version, 
called  MODEL  II  is  an  operational  system  with  a 
simplified  user-oriented  language  [PRY  77a].  A new 
version  of  MODEL  is  also  under  development  [GAN  75, 

SHA  76,  PRY  77b].  It  includes  interactiveness,  tolerance 
of  incompleteness  or  ambiguities,  and  modelling  and 
forecasting. 

NOPAL  and  MODEL  share  several  common  techniques 
such  as  using  Syntax  Analysis  Program  Generator  to  pro- 
duce a syntax  parser,  encoding  statements  in  a simulated 
associative  memory  to  facilitate  later  retrieval,  and 
constructing  directed  graph  models  for  sequencing  and 
analysis  purpose.  But  they  differ  in  many  aspects. 

MODEL  is  designed  for  general  data  processing  and 
emphasizes  computational  capabilities,  while  NOPAL  is 

for  engineers  and  hence  focuses  more  on  providing  engineer- 
ing facilities.  NOPAL  incorporates  engineering  knowledge 
base  and  fits  a particular  class  of  user,  engineer. 

MODEL  provides  more  complex  iteration  facility  and  has 


more  data  types. 


Extensive  research  on  automatic  program  generation 
has  been  conducted  at  MIT.  Research  on  automation  of 
various  phases  from  problem  definition  to  program 
compilation  and  execution  has  been  attempted  simultane- 
ously. These  efforts  have  been  integrated  in  an  auto- 
matic programming  system  prototype,  PROTOSYSTEM  I, 
which  consists  of  top  and  bottom  parts.  The  top  part 
deals  with  problem  definition  and  system  analysis  and 
design.  It  represents  (1)  an  automated  consultant 
system  for  operations  management  [HAX  73,  MAR  76], 

(2)  the  research  on  questionnaire  approaches  [MAL  75], 
and  (3)  the  development  of  the  OWL  language  for  user 
communication  [MAR  74].  The  bottom  part  addresses  the 
problems  of  implementation  and  optimization  of  a pro- 
gram, given  an  abstract  specification  of  what  to  be 
done  [RUT  76].  Thus  it  accepts  a specification  from 
the  top  part,  performs  program  design  and  optimization, 
and  finally  generates  PL/1  code  and  the  needed  job 
control  statements. 

The  MIT  research  has  tried  to  specialize  in 
assisting  the  operations  management  consultant  in 
solving  procurement  problems.  In  contrast,  NOPAL 
system  provides  engineers  with  an  automation  aid  in 
producing  test  programs. 


2.3  Literature  on  Automatic  Testing  and  Automation 

Test  Equipments 

The  advent  of  solid-state  technology  has  made  the 
electronic  components  and  systems  more  complex.  Conse- 
quently, the  problems  associated  with  testing  and  the 
testability  of  electronic  devices  and  systems  continue 
to  grow  in  complexity.  Sophisticated  testing  is 
absolutely  necessary  in  order  to  keep  the  equipment 
operational.  The  soaring  maintenance  and  support  costs 
on  these  systems  as  illustrated  in  Chapter  I have  also 
prompted  the  development  of  automatic  testing  -- 
isolating  faults  quickly  and  with  minimum  human  inter- 
vention. 

While  automatic  testing  can  be  used  in  many  other 
fields  such  as  mechanical,  hydraulic  and  optical,  the 
technique  has  been  widely  employed  in  testing  electronic 
equipment.  Therefore,  the  subsequent  discussions  focus 
primarily  on  the  automatic  testing  of  electronic  devices. 

Automatic  testing,  when  applied  to  electronic 
circuits, is  designed  to  evaluate  three  types  of  circuits: 
a)  digital,  (2)  analog,  and  (3)  hybrid.  There  are  three 
basic  testing  methods  for  digital  circuits  [McA  71, 

ELE  74]; 
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(1)  Functional  testing,  the  application  of 
binary  signals  to  determine  Boolean  operation. 

(2)  Static  or  parametric  testing,  to  check  static 
characteristics  such  as  DC  parameters. 

(3)  Dynamic  testing,  to  check  t ime -dependent  para- 
meters such  as  rise  and  fall  times,  and  pro- 
pagation delay. 

When  applied  to  analog  circuits,  functional  testing 
means  to  check  if  the  systems  perform  well  according  to 
design.  While  there  has  been  considerable  research  and 
development  on  simulation  of  digital  circuits,  there 
has  been  little  work  done  on  generating  tests  for 
analog  circuits  [GRE  73]. 

An  automatic  test  system  consists  of  several  main 
components  [TO  74]: 

(1)  Data  base  of  the  descriptions  of  the  unit 
under  test,  e.g.,  electronic  circuit 

(2)  Means  of  simulation 

(3)  Test  generation  techniques 

(4)  Command  language  and  program  library 

(5)  Automatic  test  equipment  (ATE) 

(6)  Fault  isolation 

(7)  Data  management 


r 
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To  achieve  maximum  effectiveness  of  an  ATS,  a 
concerted  effort  must  be  directed  to  all  of  these 
componen  ts . 

Automatic  test  equipment  ranges  from  simple 
fixed  program  comparator  or  pattern  generator  to  the 
variable  stored  program,  computer-controlled  test 
system.  Some  ATE  units  are  briefly  described  below. 

Automatic  test  systems  have  been  largely  used  by 
military  and  semiconductor  manufacturers  [LUS  73],  and 
are  beginning  to  be  used  in  almost  every  field,  includ- 
ing industrial  control,  manufacturing,  and  computer 
ne  two  rks . 

A good  example  is  the  electronic  switching  systems 
(ESS)  used  in  the  Bell  Telephone  System  (BEL  70,  BEL  73]. 
To  achieve  an  expected  down  time  of  two  hours  in  forty 
years.  Bell  Telephone  has  counted  on  such  automatic 
testing  methods  as  using  central  control  offices  to 
initiate  fault  analysis  automatically. 

The  industrial  spectrum  of  automatic  testing  as 
outlined  in  the  following  paragraph  was  summarized  from 
[ ELE  74  and  SEM  74 ] . 

At  Honeywell  automatic  testing  is  used  to  develop 
some  new  products.  Westinghouse  has  initiated  systems 
in  transportation,  remote  terminal,  and  contactless 
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testing.  Adar  Associates  has  been  concentrating  on 
» semiconductor  memory  and  micro  processor  testing.  Both 

Teradyne  and  Fairchild  Systems  Technology  produce 
computer-controlled  IC  testers  and  modularized  test 
systems.  Finally  System  390  by  Instrumentation,  S-3260 
by  Tektronix,  and  9500  Series  by  Hewlett-Packard  are  the 
typical  fully  automatic  test  systems. 

A remarkable  automatic  test  station,  SCATE  MARK  VI 
[GEN  73]  was  introduced  by  General  Dynamics.  It  is 
computer-controlled,  modularized,  and  capable  of  testing 
digital,  analog,  or  RF  electronics  at  frequencies  up 
to  1.3  GHz.  The  system  includes  a programmable  inter- 
face unit,  a sampling  measurement  system,  and  an 
arbitrary  stimulus  function  generator.  Thereby 
conventional  adaptors,  measurement  instruments,  and 
stimulus  generators  are  eliminated.  Moreover,  it  uses 
a high  level  test  programming  language  (ATLAS).  The 
ATE  architecture  depicted  in  Figure  1.2  has  been 
influenced  by  the  recent  advances  in  the  ATE  units  such 

1 

as  SCATE  MARK  VI. 

I 

I Many  aspects  of  automatic  testing  such  as  software 

j and  languages,  simulation,  interfacing  fault  isolation, 

failure  prediction,  and  self-repairing  circuits  are 
gaining  more  attention.  For  example.  Institute  of 
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Electrical  and  Electronics  Engineering  (IEEE)  has  held 
many  forums  (e.g.  INTERCON  and  WESCON)  and  yearly 
symposia  (e.g.  Automatic  Support  Systems  Symposium 
and  Semiconductor  Test  Symposium  [SEM  74]).  A formal 
publication  on  automatic  test  equipments  was  also 
sponsored  by  IEEE  [LIG  74]. 

2.4  Survey  of  ATE  Programming  Languages 

Programming  languages  are  used  in  stored  program, 
c ompu t e r- CO n t r o 1 1 ed  automatic  test  equipments  to  write 
test  procedures.  Some  typical  high  level,  procedural 
test  languages  are  summarized  in  the  following  para- 
graphs . 

Probably  the  most  popular  test  language  is  ATLAS 
(Abbreviated  Test  Language  for  Avionic  Systems)  a 
language  originally  developed  for  airline  avionic  equip- 
ment testing  [ARI  76].  Many  modified  versions  of  ATLAS 
also  exists.  For  example,  a version  called  EQUATE-ATLAS 
was  modified  by  RCA  for  the  U.S.  Army  EQUATE  system 
[RCA  73] . 

CTL  (Compass  Test  Language)  is  another  test  language 
developed  for  the  U.S.  Army  [WAR  74].  It  was  designed 
to  include  some  features  of  modern  high  level  programming 
languages  such  as  looping  constructs  and  decision  tables. 
Also  it  could  be  used  to  program  tests  for  UUTs  other 
than  avionic  or  electronic  equipments. 

25 


» 


GOAL  (Ground  Operations  Aerospace  Language)  was 
developed  at  NASA  JFK  Space  Center  [NAS  73].  It  is  a 
test  engineer  oriented  language,  in  which  an  engineer 
can  program  test  procedures  for  space  shuttle  pre- 
flight checkout,  ground  preflight  operations,  etc. 

Most  recently,  OPAL (Operational  Performance 
Analysis  Language)  was  developed  for  the  U.S.  Army 
(Frankford  Arsenal)  [FRA  76a].  It  is  a language  in  which 
one  can  program  tests  for  various  classes  of  devices. 
Supposedly  its  design  is  based  upon  the  concepts  derived 
from  ATLAS,  CTL , GOAL,  and  other  general  purpose  languages 
such  as  ALGOL  and  PL/1.  OPAL  is  the  objective  language  of  the 
automatic  test  program  generation  system  reported  in  this 
dissertation  and  is  covered  in  Chapter  3 in  more  detail. 

All  the  above-mentioned  test  languages  are  high 
level,  procedural.  The  user  has  to  sequence  his  test 
steps  and  takes  care  of  storage  assignments,  etc.  In 
essence,  they  are  like  general  purpose,  high  level  pro- 
gramming languages  except  that  they  also  provide  test- 
oriented  capabilities.  Therefore  the  higher  level  or 
non-procedural  NOPAL  language  was  introduced.  The  user 
can  describe  rather  than  program  his  tests  in  this 
language,  hence  lower  level  programming  details  are 


eliminated. 


CHAPTER  3 


THE  NOPAL  AND  OPAL  LANGUAGES 


3.1  Introduction 

The  objective  of  this  chapter  is  to  present  the 
source  and  target  languages  of  the  automatic  test  pro- 
gram generation  system.  Sections  3.2  and  3.3  describe 
the  source  language  NOPAL  (Non-procedural  OPAL)  and 
Section  3.4  presents  the  target  language  OPAL  (Oper- 
ational Performance  Analysis  Language). 

NOPAL  is  a very  high-level,  non-procedural  language 
in  which  a set  of  tests  and  diagnoses  for  a unit  under 
test  (UUT)  can  be  easily  described.  It  is  non-procedural 
in  the  sense  that  its  statements  are  descriptive  and  can 
be  entered  in  any  order,  that  it  does  not  provide 
facilities  for  stating  commands  or  sequencing  and  control 
logic,  and  that  additional  statements  can  be  incrementally 
included.  This  language  was  developed  to  facilitate  the 
process  of  automated  design  and  programming  of  testing. 

OPAL,  in  which  the  object  program  outputted  from 
this  system  is  written,  is  a high  level,  procedural  test 
language  for  programming  automatic  test  equipments  (ATE). 
Its  definition,  syntax,  and  semantics  have  been  fully 
documented  [FRA  76  ].  This  documentation  should  be 


referred  to  for  more  details;  Section  3.4  only  high- 
lights this  language. 

One  major  disadvantage  for  a test  engineer  to  use 
OPAL  directly  is  that  he  has  to  "program"  the  tests 
rather  than  "describe"  them.  He  must  also  be  a computer 
programmer,  sequence  his  test  steps,  plan  storage 
assignments,  and  so  forth.  Therefore  NOPAL  was  intro- 
duced to  overcome  these  drawbacks  by  substituting  an 
automatic  process  for  human  programmers.  NOPAL  is  a 
specification  scheme  in  which  the  test  engineer  can  des- 
cribe what  to  be  done  disregarding  how  to  do  it.  He 
should  be  able  to  master  this  methodology  fast  and  easily. 
On  the  other  hand,  an  automatic  test  determination  process 
can  effectively  generate  test  specifications  described 
in  NOPAL.  The  burden  of  lower-level  details  is  left 
to  the  NOPAL  processor. 

3.2  The  NOPAL  Language 

This  section  describes  the  syntax  and  semantics 
of  the  NOPAL  (Non-procedural  OPAL)  language.  NOPAL  is  a 
description  language  in  which  test  specifications  can 
be  described  effectively. 

A collection  of  NOPAL  statements  describing  a 
functional  module  is  referred  to  as  a specification.  A 
complete  description,  in  NOPAL,  of  the  tests  desired 
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for  a given  UUT  and  under  a given  ATE  is  referred  to  as 


a NOPAL  specification  or  test  specification.  NOPAL 
statements  are  delimited  by  statement  end  markers  (;). 

They  can  appear  in  any  order  due  to  the  nature  of  non- 
proceduralness. Yet  for  organization  purposes,  each 
test  specification  can  be  divided  into  the  following 
three  major  sections  immediately  after  a specification 
header  statement  which  identifies  the  whole  specifi- 
cation: 

(1 ) test-modules  specification  which  describe 

the  set  of  desired  tests  including  the  stimuli 
to  be  applied,  measurements  to  be  made,  logic 
to  be  used  for  selecting  diagnoses,  and 
definitions  of  the  diagnoses  and  messages; 

(2)  UUT  specification  whose  statements  identify  the 
potential  component  failures  and  connection 
points  of  the  UUT; 

(3)  ATE  specification  which  defines  the  ATE 
functions  (such  as  stimuli,  measurement s, and 
special-purpose  computational)  and  the  ATE 
int er- connec t ing  points. 

The  last  two  sections  are  described  in  Sections  3.2.4 
and  3.2.5  respectively.  The  test-modules  specification 
is  discussed  separately  in  Section  3.3  due  to  its 


complexi ty . 


Section  3.2.1  introduces  a new  syntax  notation, 
which  is  extended  from  conventional  Backus  Normal  Form, 
and  the  complete  formal  syntax  of  NOPAL  in  this  meta- 
language. 

To  make  it  easier  to  explain  the  NOPAL  language 
a sample  test  specification  is  presented  in  Section  3.2.2. 

Section  3.2.3  summarizes  the  fundamental  lexical 
constructs  which  are  used  to  form  higher  level  NOPAL 
s ta  t emen  t s . 

Note  that  in  the  NOPAL  language,  if  a keyword 
is  composed  of  more  than  five  characters,  only  the  first 
four  characters  are  significant  (and  such  keywords  are 
listed  in  Table  5.5  of  Chapter  5). 

3.2.1  Extended  BNF  Syntax  Notation 

In  the  subsequent  descriptions  of  the  syntax  of 
NOPAL  statements,  a meta- language  EBNF  (Extended  Backus 
Normal  Form)  is  used.  EBNF  and  its  processor  were 
developed  at  the  University  of  Pennsylvania  by  the  DDL 
project  [RAM  73  and  FRE  72].  They  are  further  discussed 
in  Section  5.2  of  Chapter  5.  As  in  conventional  BNF, 
names  enclosed  by  angle  brackets  < >,  called  non- 

terminals, represent  syntactic  classes  for  which  specific 
items  are  eventually  to  be  substituted,  and  non-bracketed 
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names  represent  terminal  symbols.  The  symbol  means 


"is  defined  as"  or  "produces".  The  vertical  bar  | 
denotes  "or",  and  is  used  for  alternatives.  The  two 
extensions  to  the  conventional  BNF  are  optionallty 
and  repetition . Units  enclosed  in  square  brackets  [ ] 

indicate  that  they  are  optional,  i.e. , they  may  appear 
zero  or  one  time.  If  an  asterisk  also  follows  the 
right  square  bracket,  i.e.  [ ]*,  it  means  that  the 

enclosed  item  may  be  repeated  zero  or  more  times. 

The  complete  formal  syntax  of  NOPAL  in  EBNF  is 
presented  in  Figure  3.1.  To  enhance  readability,  EBNF 
statements  (productions)  are  indented  and  assigned  level 
numbers  to  indicate  the  depth  within  the  syntax-tree 
structure.  Numbers  to  the  right  of  the  EBNF  specifi- 
cation are  the  corresponding  EBNF  statement  (or  pro- 
duction) numbers,  which  will  be  referred  to  in  later 
discussions . 

3.2.2  A Sample  NOPAL  Specification  - MINIRADIOSET 

In  order  to  facilitate  the  discussion  of  the 
various  aspects  of  the  NOPAL  language  and  demonstrate 
its  usage,  a sample  test  specification  written  in  NOPAL 
is  presented  in  Figure  3.2.  This  specification  (refer- 
red to  as  MINIRADIOSET)  along  with  a variety  of  reports 
produced  by  the  NOPAL  processor  can  also  be  found 
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I IC.DIU-  5.  1 EBNF  SPECIFICATION  OF  NOPAL 


FKUIfii:  i.  1 EBNF  SPnCIFICATIO'l  OF  NOPAl.  (continued) 
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EBNF  Sl’ECIFICATKN  OF  NOPAL  (contuiued) 
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FIGURE  3.1  EBNF  SPECIFICATION  OF  NOPAL  (continued) 
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IJlCUKi;  5.  1 EBNF  SPECIFICATICN  OF  NOPAL  (continued) 
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FIGURE  3. 1 EBNF  SPECIFICATICN  OF  NOPAL  (continued) 
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in  Appendix  B.  This  sample  problem  will  be  referenced 
frequently  in  the  subsequent  sections  of  this  chapter 
and  also  in  later  chapters. 

This  example  describes  a specification  consisting 
of  six  tests  on  a radio  set. 

It  begins  with  the  specification  of  six  tests  (DC- 
input,  amplitude,  2W-aud io-di s t or t i on , distortion- 
reference-voltage,  frequency,  and  lOw-aud io-d i s t or t ion ) 
together  with  all  the  messages  referred  to  in  the  tests. 
Then  it  identifies  the  UUT  connecting  points  and 
component  failures.  Finally,  the  ATE  functions  and  inter- 
connecting points  are  defined. 

The  numbers  on  the  left-hand  side  are  NOPAL  state- 
ment numbers  generated  and  printed  by  the  NOPAL  processor. 
Note  that  only  one  ATE  inter-connecting  point  (ATE_J24B) 
is  included  in  the  specification.  It  is  an  over  simpli- 
fication intended  for  demonstration  purpose.  The  set 
of  real  ATE  inter-connecting  points  should  be  available 
and  must  be  properly  identified  in  the  ATE  specification 
section,  when  the  UUT  is  actually  connected  to  a real 
ATE  for  performing  the  tests. 

3.2.3  Fundamental  Constructs  of  NOPAL 

Fundamental  syntax  units  used  in  NOPAL,  as  shown 
in  productions  1 through  52  of  Figure  3.1,  are  briefly 
discussed  in  this  section. 
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A strlgg  constant  is  either  a character  string; 


or  a bit  string.  Character  strings  are  composed  of 
any  number  of  any  characters  enclosed  in  single  quotes 
(')•  If  a single  quote  is  part  of  the  string,  it  is 
represented  by  two  consecutive  quotes.  Bit  strings 
are  sequences  of  O's  and  I's  enclosed  in  single  quotes 
and  immediately  followed  by  the  character  B.  For 
example,  'FREQ'  and  'PRESS  STOP'are  character  strings. 
'I'B  is  a bit  string.  String  constants  are  primarily 
used  as  arguments  of  functions;  character  strings  are 
also  used  to  compose  diagnosis  messages. 

A sequence  of  characters  enclosed  by  /*  and  */  is 
a comment . For  example,  /*  TEST  MODULES  */  is  a 
comment.  Comments  are  for  the  purposes  of  documenta- 
tion only,  and  they  are  treated  as  blanks. 

A number  in  NOPAL  can  be  signed  or  unsigned, 
integer  or  floating  point  and  may  include  an  exponential 
part,  such  as  0.26,  - 10,  and  5E6 . 

An  identifier  is  a sequence  of  alphanumeric  char- 
acters, beginning  with  a letter.  The  twenty-six  alpha- 
bets and  four  special  characters  ( (? , It,  $,  and  _)  are 
letters.  For  instance,  DC_INPUT,  VI,  and  #17  are 
identifiers.  Identifiers  are  used  as  names  for 
identifying  certain  entities. 

4 7 


A var  table  can  be  a simple  variable  which  is  an 
identifier,  or  a subscripted  variable  which  consists 
of  an  identifier  and  a parenthesized  subscript  list. 

A subset  jpt  list  is  composed  of  one  or  more  arithmetic 
expressions  separated  by  commas.  For  example,  MRE’S 
and  VI  are  variables.  Variables  are  names  which 
represent  a data  item  that  can  take  on  different 
values  during  the  execution  of  a program. 

An  arithmetic  expression  is  a combination  of  numbers, 
variables  and  function  calls  connected  by  mathematical 
operators  (+,  *,  /,  and  **)  that  yield  a value  when 

evaluated.  A function  call  consists  of  an  identifier 
possibly  followed  by  a parenthesized  list  of  arguments 
separated  by  commas.  An  ar gument  is  an  arithmetic 
expression  or  a string  constant.  Function  calls  always 
return  a value  when  invoked. 

A relational  expression  consists  of  two  arithmetic 
expressions  separated  by  one  of  the  relational  operators 
(”,  >,  < , , < ■,  >«,  etc.)  which  evaluate  to  either 

TRUE  or  FALSE  logical  value.  A Boolean  term  is  a logical 
expression  consisting  of  the  relational  expressions  which 
are  connected  by  logical  operators  (NOT) , | (OR) , and 


i 

1 

I 

1 

i 

i 
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&{AND).  An  if-clause  is  a Boolean  terra  enclosed  by 
the  two  keywords  IF  and  THEN,  and  is  used  to  specify 
a conditional  statement  (conjunction  or  assertion).  For 
example,  "IF  VARl  - 60  THEN"  is  an  if-clause,  which 
includes  a Boolean  terra  (also  a relational  expression) 

"VARl  • 60".  Relational  expressions  are  also  used  to 
form  simple  assertions  (see  Section  3. 3. 1.3). 

A connector  dimension  expression,  which  is  used  to 
specify  a set  of  UUT  test  points,  is  composed  of  a 
connector  and  optionally  a dimension.  A connector  is 
a single  UUT  point  name,  or  a list  of  UUT  point  names 
enclosed  by  angle  brackets  < >.  Dimens  ions  are  physical 

units  of  measure,  such  as  VOLT,  AMP,  SEC,  etc.  Thus 
< J19_;A,  GND  > is  a connector  dimension  expression. 

A value  dimension  expression  is  an  arithmetic 
expression  possibly  followed  by  a dimension,  and  is 
used  as  an  argument  of  a stimulus  or  measurement  function. 

For  example,  MRES  OHM  and  25.002MHZ  are  value  dimension 
expressions . 

A function  dimension  expression  is  a combination  of 
function  primaries,  constants,  and  mathematical  operators 
(+,  -,  *,  and  /).  Its  basic  unit  is  function  primary, 
which  consists  of  a function  identifier  followed  by  a 
parenthesized  list  of  functional  arguments.  A func  t ional 
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argument  can  be  a value  dimension  expression  optionally 
prefixed  by  a relational  operator,  a range,  a string 
constant,  or  an  asterisk  (*)  meaning  "don't  care".  A 
range  is  composed  of  two  value  dimension  expressions 
separated  by  the  operator  H — , the  first  expression 
specifies  nominal  value  and  the  second  tolerance.  Func- 
tion dimension  expressions  are  used  to  express  wave- 
form conjunctions  in  the  stimuli  or  measurements  (to 
be  further  discussed  in  Section  3.3.1).  In  the  current 
version  of  the  NOPAL  processor,  they  have  been  imple- 
mented as  function  primaries  only.  Thus,  CONST_R(MRES 
OHM)  and  SIGNAL_AM(25 . 002  MHZ,  + 13DB,  0%,  1 KHZ)  are 
function  dimension  expressions. 

3.2.4  UUT  Specification 

The  UUT-oriented  information  needed  for  the  auto- 
matic test  program  generation  is  grouped  into  two 
sections;  (1)  UUT  connecting  points  which  identify  the 
connecting  pins  for  the  testing  and  (2)  component 
failures  which  define  all  the  potential  faulty  components 
with  failure  modes  (i.e.  types  of  failures).  This  is 
used  in  conjunction  with  the  test-modules  specification 
(Section  13.3)  for  the  purpose  of  identifying  UUT 
connecting  points  and  component  failures,  and  for  check- 
ing the  correctness  and  completeness  of  the  specified 
tests  . 
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3. 2. 4.1  UUT  Connecting  Points 

This  section  consists  of  a collection  of  UUT 
connecting  points.  The  top  level  structure  for  a UUT 
connection  point  is  shown  in  Figure  3.3(a),  corres- 
ponding to  productions  119-121  of  Figure  3.1.  It 
begins  with  the  keyword  UUT_POINT.  Then  an  internal 
sequence  number  and  a delimiter  (:)  may  optionally 
follow.  The  internal  sequence  numbers,  which  are 
optional  and  have  no  semantics,  enable  the  user  to 
enumerate  the  set  of  UUT  points  in  a certain  sequence 
if  he  so  desires.  Next  comes  a symbolic  name  (identi- 
fier) to  identify  the  connecting  point.  Finally  one 
or  more  of  the  following  keyword  attributes  may 
optionally  appear: 

(1)  a synonym  to  the  UUT  point  identifier.  This 
name  is  used  to  identify  a single  point  or 

a class  of  connecting  points. 

(2)  connector  type  and  point  identification. 

(3)  protective  limits  which  consist  of  dimension, 

maximum  limit,  minimum  limit,  and  reference 

point  enclosed  in  parentheses  and  separated 

* 

by  commas.  This  information  is  used  to 
protect  the  connecting  point  from  inadvertent 
damage  caused  by  excessive  stimuli  power. 
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(a)  UUT  Connecting  Point 


< UUT_CONNECTION_POINT  > 

UUT_POINT  [<  SEQ//  >J  [:]<  UUT_POINT_ID  ^ 
[,<  UUT_POINT_KEYWORD  >]*; 

< UUT_POINT_KEYWORD  >::* 

ALIAS  - < SYNONYMN  > 
j CONNECTOR  - < UUT_CONNECTOR  > 
j LIMIT  - < PROTECTIVE_LIMITS  > 

I c COMMENTS  > 

(b)  Exa  mp  1 e 

UUT_POINT  2:  J24_B,  ALIAS  - XJ24_B, 

CONNECTOR  « (MULTIPLE,  B), 

LIMIT  = (VOLT,  35,  20  . GND). ; 


FIGURE  3,3 

TOP  LEVEL  STRUCTURE  AND  EXAMPLE  OF  UUT  CONNECTION 

POINT 
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(4)  Any  c omment s enclosed  in  single  quotes  after 
the  optional  "COMMENT-". 

Figure  3.3(b)  illustrates  a sample  UUT  connection 
point  specification.  The  second  UUT  point,  called 
J24-B  or  XJ24-B  is  connected  to  point  B of  a multiple 
connector.  The  protective  limits  are  35  volts  for  the 
maximum  and  20  volts  for  the  minimum  with  respect  to 
another  connecting  point  called  GND . 

3. 2. 4. 2 UUT  Component  Failures 

All  the  potential  affected  components  (components 
with  corresponding  failure  modes)  must  be  listed  in 
this  section  in  order  to  identify  affected  components, 
to  check  completeness,  and  to  produce  fault  isolation 
statistics.  The  top  level  syntax  for  each  such  entry 
is  depicted  in  Figure  3.4(a).  It  consists  of  the 
following  items  in  that  order  after  the  keyword 
C0MP__FAIL: 

(1)  An  optional  sequence  number  to  uniquely 
identify  the  component  together  with  the 
failure  node.  This  number  may  be  referenced 
in  the  a f f e c t ed-componen t s part  of  diagnoses, 
or  in  the  comp onent -p ro t ec t ion  (3-e)  of  this 
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section: 


(a)  UUT  Component  Failure 


<UUT_COMPONENT_FAILURE > 

COMP_FAIL  [<SEQ#>  ] [:]  < COMPONENT  > 

[,  <COMP_FAIL_KEYWORD > ]*; 

<COMP_FAIL_KEYWORD > ALIAS  - <SYNONYM  > 

1 FAILURE  [FUNCTION]  - < FAI LURE_FUNCT I ON> 

I PARAMETER  « <PARM_LIST> 

1 INDEX  * <FAILURE_INDEX> 

1 PROTECTION  = < COMPS_PROTECTED> 

1 <COMMENTS> 

(b)  Example 

COMP_FAIL  3:  STD_5MHZ_FREQ , FAIL  FUNC  - AMPL_TOL, 
INDEX  - 2,  PROTECTION  = 1; 


FIGURE  3.4  TOP  LEVEL  STRUCTURE  AND  EXAMPLE 
OF  UUT  COMPONENT  FAILURE  SPECIFICATION 
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(2)  A symbolic  name  (identifier)  for  the 

c omponen t . The  component  is  identified 

by  this  name  or  its  synonym  specified  in  3(a). 

(3)  One  or  more  of  the  following  keyword  attributes 

may  be  included  optionally: 

(a)  A synonym  to  the  component  identifier. 

(b)  A failure  function  to  indicate  the  type 
of  failure  for  the  component  (e.g.  Open, 
short,  out-of-tolerance). 

(c)  Any  other  parameters  of  the  failure 
function,  if  any. 

(d)  A failure  index  which  is  an  integer  used 
to  index  the  components  by  their  likeli- 
hood of  failure.  The  smaller  the  index 
value,  the  larger  the  failure  likelihood 
will  be.  This  information  could  be  used 
to  obtain  execution  efficiency  by  first 
testing  the  components  which  are  more 
likely  to  fail. 

(e)  Component  protection  - a list  of  other 
affected  components  whose  failures  will 
prohibit  the  testing  of  this  component. 

(f)  Any  comment  s enclosed  in  single  quotes. 


55 


Figure  3.4(b)  illustrates  a sample  UUT  component 
failure  specification.  An  affected  component,  numbered 
3,  consists  of  a component  STD_5MH_FREQ  and  a failure 
function  AMPL_TOL.  It  is  given  a failure  index  2 and 
is  protected  by  affected  component  1 (which  turns  out 
to  be  component  INPUT_SHORT) . 


3.2.5  ATE  Specification 

ATE  related  information  which  is  needed  to  verify 
the  test-modules  and  UUT  specifications  is  organized  in 
two  sections:  (1)  ATE  connecting  points  which  are  con- 

nected to  the  matching  UUT  connectors  and  (2)  ATE 
functions  specified  in  the  stimuli  and  measurement 
sections  of  the  test  modules. 

3. 2. 5.1  ATE  Connecting  Points 

This  section  describes  the  ATE  inte r-connec t ine 
points  which  are  interfaced  with  the  matching  UUT 
connecting  points.  The  top  level  syntax  of  an  ATE 
connecting  point  statement  is  shown  in  Figure  3.5(a). 

It  consists  of  the  following  items  in  that  order,  after 
the  keyword  ATE-POINT: 


(a)  ATE  Connecting  Point 


ATE_CONNECTION_POINT  > 

ATE_POINT  [<  SEQ//  >]  [:]  < ATE_POINT_ID  > 

[,  < ATE_POINT_KEYWORD  > ]*; 

< ATE_POINT_KEYWORD  > ALIAS  = < SYNONYM  > 

I UUT_POINT  =«  < UUT_POINTS  > 

I < COMMENTS  > 

(b)  Example 

ATE_POINT:  ATE_J24B,  UUT_POINT  - J24_B; 


FIGURE  3.5 

TOP  LEVEL  STRUCTURE  AND  EXAMPLE  OF  ATE  CONNECTING  POINT 


(1)  an  optional  internal  sequence  number,  which 
has  no  semantics.  These  numbers  allow  the 
user  to  enumerate  the  set  of  ATE  points. 

(2)  a name  (identifier)  for  the  ATE  connection 
point . The  ATE  point  can  be  identified  by 
this  name  or  its  synonym  specified  in  3(a). 

(3)  Optionally  any  of  the  following  keyword 
attributes  may  appear; 

(a)  a synonym  to  the  ATE  point. 

(b)  a list  of  matching  UUT  connecting  points 
to  which  the  ATE  point  is  connected. 

(c)  any  comment  s enclosed  in  single  quotes. 

Figure  3.5(b)  illustrates  a sample  ATE  connecting 

point  specification.  The  ATE  connecting  pointed  is 
called  ATE_J24B  and  is  connected  to  a UUT  connection 
point  called  J24-B. 

3. 2. 5. 2 ATE  Functions 

Functions  used  for  the  specification  of  stimuli, 
measurements,  and  component  failures  must  be  listed  in 
this  section.  Purely  computational  functions,  or 
iteration  control  functions,  may  also  be  used  and 
listed  here.  The  top  level  syntax  of  a function  entry 
is  depicted  in  Figure  3.6(a).  It  is  composed  of  the 
following  items  in  that  order  after  the  keyword  FUNCTION 


(a)  ATE  Function 

<ATE_FUNCTION>  : :* 

FUNCTION  [ <SEQ//>  ] [:]  <FUNCT  ION_I  D > 

[,  <FUNCTION_KEYWORD  > ] * ; 
<FUNCTION  KEYWORD>  ::=  ALIAS  = < SYNONYM > 

I [FUNCTION]  TYPE  = <FUNCTION_TYPE> 

1 //PINS  = <UNSIGNED_INTEGER> 

I PARAM  = <PARM>  [,  PARAM  = <PARM>  ]* 

I VALUE  [RETURNED]  - < VALUE_RETURNED> 

1 COOPERATION  = <COOP_FUNCTIONS> 

1 < COMMENTS > 

(b)  Example 

FUNCTION  10:  CONST_S,  FUNCTION  TYPE  » S, 

PARAM  = (X,S,  LIMIT  “(VOLT,  60,  0)), 

VALUE  RETURNED  = 'CONSTANT  VOLT.’; 


FIGURE  3.6 

TOP  LEVEL  STRUCTURE  AND  EXAMPLE  OF  ATE  FUNCTION 
SPECIFICATION 
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(1)  An  optional  internal  sequence  number.  which 
aids  to  enumerate  the  set  of  ATE  functions. 

(2)  a function  identifier,  i.e.,  name  of  the 
function.  Thus  the  function  can  be  identified 
by  this  name  or  its  synonym  specified  in  3(a). 

(3)  any  of  the  following  keyword  attributes  may 
optionally  appear. 

(a)  a synonym  to  the  function  identifier. 

(b)  a function  type  which  is  S(stimuli), 

M (Measurement),  F(Failures),  E(Evalu- 
ation),  or  C(controls).  E is  the  default. 

(c)  The  number  of  pins  needed  for  a function 
of  type  S or  M.  2 is  the  default. 

(d)  A list  of  parameters . each  may  include  a 
parameter  name,  parameter  types  (S  for 
SOURCE,  or  T for  TARGET),  and  parameter 
limits  indicating  dimension,  maximum  and 
minimum  values. 

(e)  a description  of  the  value(s)  returned 
from  this  function,  enclosed  in  quotes. 
This  serves  as  a comment  about  the  value 
returned  only,  hence  no  semantics  is 
associated  with  it. 
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(f)  a list  of  cooperating  functions  which  are 
needed  for  parallel  execution  with  this 


function.  This  applies  especially  to  the 
synchronization  between  cooperating  stimuli 
and  measurement  functions, 

(g)  any  comments  enclosed  in  quotes 
Figure  3.6(b)  shows  an  example  of  ATE  function 
specification.  The  function  is  given  a sequence  number 
10  and  is  called  C0NST_S.  It  is  a stimulus  function 
and  has  one  parameter  of  SOURCE  type.  This  parameter 
should  never  exceed  60  volts  or  go  below  0 volt.  The 
function  returns  a constant  voltage. 

3.3  Test  Modules  Specification 

This  section  includes  a collection  of  test  modules 

1 

and  the  definitions  of  the  diagnoses  and  messages  which 
are  referenced  in  any  test  module. 

Its  overall  structure  is  summarized  in  Figure  3.7. 

The  detailed  syntax  of  the  whole  test-modules  specifi- 
cation is  included  in  productions  57  through  106  of 
Figure  3.1. 

The  test-modules  specification  is  the  core  of  the 
NOPAL  specification  and  is  most  complex  to  prepare.  To 
reduce  the  complexity,  yet  to  provide  the  essential 
information,  each  test  module  is  specified  independently 
of  the  others.  Thereby  individual  test  modules  can  be 


< TEST_MODULES_SPECIFICATION 

[ < TEST_MODULES  >]*  [<  DIAGNOSIS  >]* 

[ < MESSAGE  > ] * 

< TEST_MODULE  >::«  [<  STIMULI  >]  [<  MEASUREMENT  >] 

[ < LOGIC  > ] 

< STIMULI  [<  CONJUNCTION  > ] [ < AS S ERTI ON  > ] * 

< MEASUREMENT  [<  CONJUNCTION  >] 

[ < ASSERTION  > ] * 

< LOGIC  >::=  [<  OPERATOR  > < D lAGNOS I S_ID  >]* 

< DIAGNOSIS  >::«<  DIAGNOSIS  ID  > 

[ < OPERATOR  MESSAGE  >]  [ < OPERATOR  RESPONSE  > ] 

<OPERATOR_MESSAGE>  = 

[ < FAILURE_IDS  >]  [ < OTHER_DATA  > ] 

< MESSAGE_ID  > [ < TIMING  >] 

< MESSAGE  MESSAGE  ID  ><  MESSAGE  TEXT  > 


FIGURE  3.7  TOP  LEVEL  STRUCTURE  OF 
TEST  MODULES  SPECIFICATION 
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modified,  deleted,  or  added  without  affecting  the  rest 
of  the  test  modules.  The  objective  of  a test  module  is 
to  describe  a single  test  which  diagnoses  some  failures. 

As  depicted  in  Figure  3.7,  a test  module  is  composed 
of  stimuli,  measurements,  and  logic.  They  are  discussed 
in  Section  3.3.1.  Diagnoses  which  are  referenced  in  the 
logic  parts  of  the  test  modules,  are  presented  in 
Section  3.3.2.  Finally  the  messages  which  are  referred 
to  in  the  diagnoses  are  covered  in  Section  3.3.3. 

3.3.1  Test  Modules 

This  section  describes  the  three  major  components  of 
a test  module  (in  addition  to  the  test  module  label): 

(1)  the  3 1 imu 1 i that  need  to  be  applied  to  the  UUT  at 
test  time,  (2)  the  measurements  that  need  to  be  made  with 
the  comparisons  that  will  determine  the  results,  and  (3) 
the  logic  that  selects  diagnoses  based  on  the  results. 

Syntactically,  a test  module  is  fully  described  by 
the  above-mentioned  three  major  components  (which  are  to 
be  discussed  in  the  subsequent  sections),  plus  the 
following  test-module  header  statement  : 

TEST  [ < TEST_LABEL  > ] ; 

where  the  optional  < TEST_LABEL  >,  which  is  either  an 
identifier  or  unsigned  integer,  is  used  to  identify  the 
test  module.  For  example,  "TEST  DC_INPUT:"  is  a test 
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header  statement  which  identifies  a test  module  called 


DC_INPUT. 

3. 3. 1.1  Stimuli  and  Measurements 

Stimuli  and  measurements  have  the  same  syntax 
structure.  This  common  syntax  is  shown  in  Figure  3.8 
(a  and  b).  The  only  difference  is  the  keyword  (STIMULI 
versus  MEASUREMENT).  Each  component  is  briefly  discussed 
as  follows : 

(1)  Keyword  (STIMULI  or  MEASUREMENT)  used  to 
specify  the  respective  type  of  entity. 

(2)  An  optional  label  of  the  stimuli  or  measurement 
for  identification  purpose.  It  can  be  either 
an  identifier  or  unsigned  integer,  and  must 

be  unique  in  the  collection  of  all  stimuli  and 
measurements  . 

(3)  An  optional  test  label  enclosed  in  parentheses 
used  to  identify  the  "parent"  test  module  with 
which  the  stimuli  or  measurement  is  associated. 
This  parental  relationship  ensures  the  pure 
non-proceduralness  of  the  statements.  If  this 
field  is  not  specified  by  the  user,  the  NOPAL 
processor  would  assign  by  default  the  last  test 
module  as  its  parent. 

(4)  Waveforms  which  consist  of  one  c onj  unction  and/ 
or  one  or  more  assert  ions  (to  be  further  dis- 
cussed in  Sections  3. 3. 1.2  and  3. 3. 1.3). 
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(a)  Stimuli 

STIMULI  [<  STIMULI_LABEL  >]  [ ( < TEST_LABEL  >)]; 

[<  CONJUNCTION  >]  [<  ASSERTION  >]* 

(b)  Measurements 

MEASUREMENT  [ < MEASUREMENT_LABEL  >]  [ ( < TEST_LABEL  >)] 

[<  CONJUNCTION  >]  [<  ASSERTION  >]* 

(c)  Sample  Stimuli  Statement 
STIMULI  DCV_AMS  ( D I S TORT_VOLT ) ; 

(d)  Sample  Measurement  Statement 
MEASUREMENT  (D I STORT_VOLT) ; 


FIGURE  3.8  SYNTAX  STRUCTURES  OF  STIMULI 
AND  MEASUREMENTS  WITH  EXAMPLES 
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Figure  3.8(c)  illustrates  a sample  stimuli  state- 
ment. The  stimulus  is  called  DCV-AMS  and  is  contained 
in  a test  module  DISTORT_VOLT . Figure  3.8(d)  demon- 
strates a measurement  statement.  The  measurement  is 
a part  of  test  module  DISTORT_VOLT , but  is  not  given  a 
name . 

3. 3. 1.2  Conjunctions 

The  conjunction  part  of  the  stimuli  or  measurement 
is  used  to  describe  UUT  connecting  points  and  the 
stimuli  functions  to  be  applied  or  the  measurements  to 
be  performed.  The  basic  form  of  this  part  is  a 
conjunction  of  triplets  (explained  later),  hence  the 
name  "conjunction"  is  adopted.  The  syntax  is  depicted 
in  Figure  3.9.  All  the  components  after  the  keyword 
CONJUNCTION  are  briefly  discussed  in  the  subsequent 
paragraphs . 

(1)  An  optional  label  (identifier  or  unsigned 
integer)  for  the  conjunction  which  must  be  distinct  in 
the  set  of  all  the  conjunctions  and  assertions  in  the 
current  test  module. 

(2)  An  optional  parenthesized  stimulus  or  measure- 
ment label  used  to  identify  the  "parent"  stimulus  or 
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< CONJUNCTION  > : : 


CONJUNCTION  [<  LABEL  >]  [(<  PARENT  >)]; 

< CONJUNCTION_BODY  >[  < DECLARATION  >]*; 

< CONJUNCTION_BODY  >::=<  TRIPLET_CON JUCT  > 

I < BACK_REFERENCE  > 

< TRIPLET_CONJUNCT  >::=<  S IMPLE_CONJUNCT ION  > 

j < IF_CONJUNCTION  > 

< SIMPLE_CONJUNCTION  >:;=<  TRIPLET  >[&<  TRIPLET  >]* 

< TRIPLET  > : : = 

[(]  < C0NN_DIM_EX  > < RELATION  > 

< FUNC_DIM_EX  > [) ] 

< IF_CONJUNCTION  >::=<  IF_CLAUSE  ><  SIMPLE_CONJUNCTION  > 

[ELSE  < TRIPLE_CONJUNCT  >] 

< BACK_REFERENCE  >::=  [SAME]  AS  < STIM_MEAS_LABEL  > 

[EXCEPT  < SIMPLE_CONJUNCTION  >] 

< DECLARATION  >::=<  VAR_TYPE  >[:]  < VAR_LIST  > 

< VAR_TYPE  > SOURCE] TARGET 

< VAR_LIST  >::»  [(]<  VARIABLE  >[,<  VARIABLE  >]*  [)] 


FIGURE  3.9  SYNTAX  STRUCTURE  OF  A CONJUNCTION 
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measurement  with  which  the  current  conjunction  is  i 

associated.  If  this  field  is  not  given  by  the  user,  1 

i 

then  the  NOPAL  processor  assumes  by  default  the  most  ' | 

) 

recent  stimulus  or  measurement  as  the  parent  of  the  | 

conjunction.  j 

■J 

j 

(3)  There  are  two  ways  of  specifying  the  con  j unc - i 

1 

t ion  body , triplet  conjunct  or  back-reference.  A j 

triplet  con  1 unc  t is  a simple  or  conditional  conjunction  i 

i 

of  triplets.  A triplet  consists  of  three  parts:  (a) 

a connector  dimension  expression  whichspecifiesaset  I 

of  UUT  connection  points  where  a waveform  function  is  to 

be  applied  to  or  measured  from,  (b)  a relation  operator,  I 

equal, sign  «,  and  (c)  a function  dimension  expression 

which  describes  the  waveform  function(s)  to  be  applied  j 

■j 

or  measured.  Refer  to  section  3.2.3  for  more  details  | 

about  these  three  parts.  Triplets  are  the  basic  units  1 

of  a conjunction.  They  are  connected  by  a conjunction  j 

operator  &,  and  each  of  them  may  optionally  be  enclosed  I 

\ 

, 

in  parentheses.  Back-reference  is  a convenient  way 
of  referencing  another  conjunction  section  which  has 
been  or  will  be  defined  in  a separate  stimulus  or 
measurement.  It  is  a simple  reference,  or  a reference 
with  modification  and/or  addition  of  some  triplets. 


68 


Note  that  only  the  conjunction  part  is  affected  and  also 
that  the  reference  is  through  the  stimuli  or  measurement 
label  rather  than  the  conjunction  label  itself.  For  more 
information  and  some  examples  about  back  reference  the 
reader  is  referred  to  Section  3. 2. 2. 4 of  [CHE  76],  which 
was  coauthored  by  this  author  and  Mr.  Che. 

(4)  Dec laration  of  variables  in  the  conjunction 
as  SOURCE  or  TARGET.  This  information  will  be  used  by 
the  NOPAL  processor  in  determining  the  execution  sequence 
of  events.  Basically,  SOURCE  variables  are  referenced 
here  but  are  generated  or  evaluated  elsewhere.  TARGET 
variables  are  evaluated  here  and  may  be  referred  to 
elsewhere.  Variables  that  are  not  explicitly  declared 
will  be  considered  to  be  SOURCE  variables,  by  default. 

Figure  3.10  illustrates  three  examples  of  unlabeiled 
conjunctions.  The  first  one  is  a measurement  conjunction. 
It  says  that  a resistance  measurement  function  CONST  R 
is  to  be  conducted  between  the  two  UUT  connecting  points 
J24-B  and  J24-C.  The  measured  resistance,  in  units  of 
ohms,  is  stored  in  a variable  MRES,  which  is  declared  as 
TARGET.  The  second  example  shows  a conjunction  in  the 
stimuli  DCV.  It  indicates  that  a constant  voltage  of 
27.5  volts  is  to  be  applied  to  UUT  points  J24-B  and  GND. 
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MEASUREMENT; 

CONJ:  < J24_B,  J24_C  >*  CONST_R(MRES  OHM) 

TARGET:  MRES ; 

STIMULI  DCV; 

CONJ:  < J24_B,  GND  > - CONST_S(27.5  VOLT) 

STIM  DCV_AMS; 

CONJ:  SAME  AS  DCV  EXCEPT 

J16  - SIGNAL_AM  (25.002MHZ,  +13DB, 

0%,  IKHZ) ; 


FIGURE  3.10 

EXAMPLES  OF  CONJUNCTIONS 
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The  last  example  demonstrates  a usage  of  the  back 
reference  in  the  conjunction  part  of  the  stimuli  DCV_AMS. 
The  conjunction  part  is  the  same  as  that  of  the  stimuli 
DCV,  except  an  amplitude  modulated  signal  SIGNAL_AM  is 
also  to  be  applied  to  UUT  point  J16.  Thus,  the  result- 
ant conjunction  part  consists  of  two  triplets,  CONST_S 
applied  to  UUT  points  J24_B  and  GND  and  SIGNAL_AM  applied 
to  UUT  point  J16 . 

3.3. 1.3  Assertions 

The  role  of  the  assertions  is  to  perform  the  pure 
computation  needed  to  supplement  the  facilities  of  the 
n'ln'-tlon*.  and  to  determine  the  selection  of  the 
. • T '1  unctions,  thev  do  not  include 

stiijll  measurement 


'S' 


a ’ ■ e r t I ’ n 


\ 
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< ASSERTION  ASSERTION  [ < LAB^L  > ] [(<  PARENT  >)] : | 

< ASSERTION_BODY  >[<  DECLARATION  >]* 

< ASSERTION_BODY  S IMPLE_AS S ERT ION  > 

I < IF_ASSERTION  > 

< SIMPLE_ASSERTION  RELATI ONAL_EXPR  > 

I < RANGE_EXPR  > 

< RELATIONAL_EXPR  > 

< ARITH_EXPR  > < RELATION  > < ARITH_EXPR  > 

< RANGE_EXPR  > : : “ 

< ARITH_EXPR  >-<  ARITH_EXPR  >+- < ARITH_EXPR  > [%] 

< IF_ASSERTION  >:;=•<  IF_CLAUSE  ><  SIMPLE_ASSERTION  > 

[ELSE  < ASSERTION  BODY  > ] [ 


FIGURE  3.11 

SYNTAX  STRUCTURE  OF  AN  ASSERTION 


measurement  with  which  this  assertion  is  associated.  If 


it  is  omitted,  then,  by  default,  the  most  recent 
stimulus  or  measurement  would  become  the  parent  of  the 
assert  ion . 

(3)  There  are  two  types  of  assertion  body:  simple 
assertion,  or  conditional  assertion.  A sl^nple  assertion 
has  also  two  forms,  a relational  expression  which  con- 
sists of  two  arithmetic  expressions  separated  by  a 
relational  operator  as  described  in  Section  3.2.3  or  a 
range  expression  which  is  a relational  expression  with 
an  equality  relation,  plus  an  expression  for  tolerance. 
The  semantics  of  assertions  are  further  explained  at  the 
end  of  this  subsection.  A conditional  assertion  is 
composed  of  if  clauses,  which  are  discussed  in  Section 
3.2.3,  and  simple  assertions. 

(4)  The  declaration  of  variables,  particularly 
TARGET  type,  in  the  assertion  is  required.  As  explained 
in  Section  3. 3. 1.2(4),  if  a variable  is  not  explicitly 
declared,  it  will  be  considered  as  a SOURCE  variable, 

by  default. 

The  range  expression  mentioned  in  the  above  item  (3) 
is  a convenient  way  of  expressing  a value  falling  within 
a certain  interval.  Each  range  expression  of  the  form; 
el  - e2  +-  e3  [Z] 

where  el,  e2,  and  e3  are  arithmetic  expressions,  will  be 
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expanded  into  the  following  two  relational  expressions  at 
code  generation  phase  (Chapter  7); 
el  e2  + e3  [*e2/100]  and 
e2  >-  e2  - e3  [*e2/100]. 

where  the  square-bracketed  expressions  appear  if  the  per- 
cent (%)  has  been  included  in  the  original  range  ,1 

1 

expression.  In  this  case,  e3  denotes  a percentage  with 
respect  to  e2  rather,  than  an  absolute  value. 


To  be  precise,  there  are  two  classes  of  simple 
assertions  in  the  forms  of  relational  expressions:  (a) 

general  relational  expressions  of  the  form  el  op  e2, 
not  involving  any  TARGET  variables,  or  (b)  special 
relational  expressions  of  the  form  X - e2;  where  el  and 
e2  are  arithmetic  expressions,  op  is  a relational  operator, 
and  X is  a TARGET  variable.  In  case  (a),  the  two 
expressions  el  and  e2  are  first  evaluated  and  compared, 
and  then  the  relational  expression  yields  a TRUE  or  FALSE 
logic  value  depending  on  the  two  evaluated  values  and 
the  operator  op.  In  case  (b),  the  arithmetic  expression 
e2  is  first  evaluated,  and  then  the  result  is  assigned  to 
tne  variable  X.  Thus  the  equal  sign  is  interpreted  as 
an  assignment  operator. 

Stimuli  and  measurement  assertions,  while  using  the 
same  syntax,  are  interpreted  differently  by  the  NOPAL 
jvr^em.  The  sflmiill  assertions  are  Interpreted  to 


generate  data  as  in  case  (b)  only.  An  assertion  in 
the  measurement  section  can  be  used  either  to  generate 
some  data  as  in  case  (b)  or  to  describe  some  condition 
as  in  case  (a).  To  simplify  the  description  of  the 
semantics,  each  measurement  assertion  that  generates 
data  may  be  considered  also  to  return  a logical  value 
TRUE . Thereby,  the  conjunctive  value  of  all  the 
measurement  assertions  and  conjunction  is  considered 
to  be  uhe  resulting  value  of  the  test  module.  Then 
the  logical  operators  (see  Section  3. 3. 1.4)  are  used 
to  select  appropriate  diagnoses  based  on  this  result 
(possibly  in  conjunction  with  the  results  of  other  test 
modules) . 

Figure  3.12  illustrates  two  examples  of  assertion 
statements.  The  first  one  is  a simple  assertion.  It 
specifies  that  the  value  of  a SOURCE  variable  MRES 
should  be  greater  than  100.  The  second  example 
demonstrates  a conditional  assertion.  Two  SOURCE  vari- 
ables VARl  and  FI  are  involved.  If  VARl  is  equal  to  60,  then 
FI  should  lie  between  (5,000,000-60)  and  (5,000,000  + 60). 
Otherwise  FI  should  be  between  (5,000,000-2.5)  and 


(5,000,000  + 2.5). 


ASSERTION:  MRES  > 100 

SOURCE:  MRES; 

ASRT:  IF  VARl  - 60  THEN  FI  - 5E6  +-  60 

ELSE  FI  » 5E6  +-  2.5; 


FIGURE  3.12  EX.*MPLES  OF  ASSERTIONS 
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3. 3. 1.4  Logic  Parts 


: ^ The  logic  part  of  the  test  modules  provides  several  j 

functions:  (1)  selects  diagnoses  based  on  the  logical  j 

values  returned  by  test  modules,  (2)  facilitates  sharing  - 

of  the  diagnoses  among  test  modules,  and  (3)  facilitates 
interactive  communication  with  the  ATE  operator.  * ! 

, The  syntax  of  a logic  statement  is  shown  in  Figure  i 

3.13(a).  It  consists  of  a list  of  pairs  of  logic 

( 

operators  and  diagnosis  labels,  in  addition  to  the  key- 
word LOGIC  and  an  optional  label.  There  are  two  types 
of  logic  operators:  (1)  logic  connectives 

&-1  , *)  by  which  a test  module  (i.e.,  a stimuli-measure- 
ment  pair)  selects  a diagnosis  and  (2)  "after"  operators 
(?,?—!  ) by  which  a diagnosis  selects  a test  module.  They 
are  further  explained  below. 

An  "or"  operator  (|)  is  used  to  indicate  that  the 
corresponding  diagnosis  will  be  selected  when  the  test 
module  returns  a TRUE  value.  An  "or-not"  operator  ( |— i) 
indicates  that  the  diagnosis  will  be  selected  if  the  test 
module  returns  a FALSE  value. 

I The  two  conjunction  operators  (&,  & — > ) are  used 

when  two  or  more  test  modules  are  required  to  select  a 
diagnosis  conjunctively.  An  "and"  operator  (&)  indicates 
that  a TRUE  value  returned  by  the  test  module  is  a 
necessary  condition  for  selecting  the  corresponding 
diagnosis.  Similarly,  an  "and-not"  operator  (i-’  ) 
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(a)  Syntax 

< LOGIC  LOGIC  [<  LABEL  >]  [:] 

[<  LOGIC_OPERATOR  ><  DIAGNOSIS_ID  >]* 
< LOGIC_OPERATOR  < LOGIC_CONNECTIVE  > 

[ < AFTER  > ] I < AFTER  > 

< LOGIC_CONNECTIVE  > : l!h|&  |&-.|  * 

< AFTER  > : : - ? I 

< DIAGNOSIS_ID  LABEL  > 

(b)  Example 

LOGIC:  I-,  D2,  *D3,  &100; 


FIGURE  3.13  SYNTAX  STRUCTURE  AND  EXAMPLE 
OF  A LOGIC  STATEMENT 
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indicates  that  a FALSE  test  result  is  necessary  for 
selecting  the  diagnosis. 

The  "don't-care”  operator  (*)  indicates  that  the 
specified  diagnosis  will  be  selected  no  matter  what  the 
testresultis.  j 

j 

The  two  "after"  operators  (?,  ?— i)  are  used  to  i 

I 

accommodate  interactive  communications  between  the  ATE  | 

computer  and  the  operator.  An  "after"  operator  (?)  | 

i 

indicates  that  the  test  module  is  to  be  executed 
immediately  after  the  diagnosis  is  selected  and  if  the 
operator  responds  "YES"  (Y).  The  "after-not"  operator 
(? — i)  exactly  does  the  same  thing  except  that  the 
operator  responds  "NO"(N).  Operator  response  is  further 
discussed  in  Section  3.3.2. 

Figure  3.13(b)  illustrates  an  example  of  logic 
statement.  Three  diagnoses  (D2,D3,  and  100)  and  three 
corresponding  logical  operators  ( |— , , *,  and  &)  are 
Involved.  If  test  result  is  FALSE  diagnosis  D2  will 
be  selected.  It  is  necessary  (but  not  sufficient)  that 
the  current  test  result  is  TRUE  in  order  to  select 
diagnosis  100.  Diagnosis  D3  will  always  be  selected 
no  matter  what  the  test  result  is. 
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3.3.2  Diagnoses 

This  section  describes  the  diagnoses  which  are 
referenced  in  the  logic  parts  of  the  test  modules.  The 
overall  syntax  structure  of  a diagnosis  is  depicted  in 
Figure  3.14.  As  indicated,  the  diagnosis  body,  after  the 

i 

I keyword  DIAGNOSIS  and  diagnosis  label,  can  be  expressed 

j in  one  of  the  two  forms:  positional  or  keyword  form. 

; Each  field  in  the  positional  form  must  be  specified  in 

: 

its  proper  position.  Fields  in  the  keyword  form  can  be 
specified  in  any  order,  but  each  of  them  must  be  pre- 
fixed with  a corresponding  keywords  and  an  equal  sign 
(=).  The  diagnosis  body  is  composed  of  two  major 
[ components:  (1)  operator  message  and  (2)  operator 

response,  each  is  briefly  discussed  below. 

The  operator  message  component  describes  the  set 
of  affected  components  and  the  message  to  be  sent.  It 
is  further  broken  into  the  following  four  parts: 

' (1)  Affected  components  - a list  of  the  component 

failures  that  this  diagnosis  asserts.  They  are  connected 
I either  by  a disjunction  operator  (|)  or  conjunction 

i operator  (&),  but  not  mixed.  Each  affected  component  can 

I be  specified  either  by  the  failure  function  followed  by 

■ the  parenthesized  component  explicitly,  or  by  the 
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< DIAGNOSIS  >::*  DIAGNOSIS  < LABEL  >[:]  < DIAG_BODY  >; 

< DIAG_BODY  POSITIOMAL_DIAG  >]  < KEYWORD_DIAG  > 

< POSITIONAL_DIAG  > ( < OPERATOR_MESSAGE  >] 

[,  < OPERATOR_RESPONSE  >] 

< OPERATOR  MESSAGE  >::=  ( [ < AFFECTED_COMPONENTS  >] 

[ , [ < OTHER_PARAMETERS  > ] [ , [ < TYPE  > ] 

[ , < TIMING  > ] ] ] ) 

< OPERATOR_RESPONSE  > > : = ? | 

[(]<  VARIABLE  >[,<  VARIABLE  >]*[)][,]  [?] 

< KEYWORD_DIAG  [OPERATOR  MESSAGE:] 

< DIAG_KEYWD  > [,  < DIAG_KEYWD  >]* 

< DIAG_KEYWD  > : 

[AFFECTED]  COMPONENT  = < AFFECTED_COMPONENTS  > 

I [OTHER]  PARAMETER  = < OTHER_PARAMETERS  > 

I TYPE  - < TYPE  > 

I TIME  = < TIMING  > 

I RESPONSE  - < OPERATOR  RESPONSE  > 


FIGURE  3.14 

SYNTAX  STRUCTURE  OF  A DIAGNOSIS  DEFINITION 
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corresponding  component-failure  sequence  number  (see 
Section  3. 2. 4. 2).  Also,  a failure  function  followed  by 
a list  of  components,  F(C1  op  C2  ...  op  Cn)  , is  an 
abbreviated  form  of  F(C1)  op  F(C2)  ...  op  F(Cn),  where  F 

is  a failure  function,  op  a disjunction  or  conjunction 
operator,  and  Ci  are  component  identifiers. 

(2)  Other  parameters  which  will  be  inserted  in 
the  diagnosis  message.  Each  parameter  is  a variable, 
number,  or  string  constant. 

(3)  Message  type  which  identifies  the  diagnosis 
message  to  be  sent  (see  Section  3,3.3). 

(4)  Timing  which  indicates  when  the  message  is  to 
be  sent  with  respect  to  the  beginning  of  the  stimuli 
application.  If  omitted,  it  means  that  the  message  will 
be  sent  upon  conclusion  of  the  test  module. 

The  operator  response  component  specifies  the 
instructions  to  the  operator  to  perform  some  duties.  It 
consists  the  following  two  parts: 

(1)  Y/N  (represented  by  ?)  response  from  the 
operator.  The  operator  instructs  to  proceed  with  the 
suspended  test  or  to  initiate  a subsequent  test  by 
responding  Y(YES).  Otherwise,  he  wants  to  discontinue 

I 
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the  normal  testing  by  responding  N(NO),  In  this  case, 
a subsequent  test  connected  by  the  "after-not" 
operator  (?— »)  may  be  initiated  next. 

(2)  A list  of  variables  into  which  the  operator 
is  requested  to  enter  a corresponding  list  of  values, 
and  to  key  in  Y to  proceed. 

Figure  3.15  illustrates  an  example  of  diagnosis 
specification,  (a)  in  positional  form  and  (b)  in  key- 
word form.  The  diagnosis  is  called  D8.  It  is  composed 
of  three  parts:  an  affected  component,  a character 
string  parameter  'AMPL'  and  a message  type  #6.  The 
affected  component  consists  of  failure  function  AMPL_TOL 
and  UUT  component  STD_5MHZ_FREQ . 

3.3.3  Messages 

Messages  can  be  shared  by  a number  of  diagnoses.  A 
few  message  types  are  considered  to  be  adequate  since 
their  actual  texts  can  be  modified  by  inserting  para- 
meters at  execution  time. 

Figure  3.16(a)  shows  the  syntax  of  a message 
definition.  It  consists  of  three  fields  after  the  key- 
word MESSAGE:  (1)  a label  (an  identifier  or  unsigned 

integer)  used  to  identify  the  message  type,  (2)  an 
optional  s',  nonym  to  the  message  label  after  the  keyword 
ALIAS  and  equal  sign,  and  (3)  message  text  which  is 


(a)  Positional  Form 


DIAGNOSIS  D8: 

(AMP_T0L(STD_5MHZ_FREQ),  'AMPL',  #6); 

(b)  Keyword  Form 

DIAGNOSIS  D8: 

COMP  - AMPL_TOL(STD_5MHZ_FREQ) , 

TYPE  - //6, 

PARAM  - 'AMPL'; 


FIGURE  3.15  EXAMPLE  OF  DIAGNOSIS  SPECIFICATION 

/ 
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(a)  Syntax 


<MESSAGE>  MESSAGE  <LABEL>  [:] 

[ALIAS  - <SYNONYM>  ] 

[TEXT-]  <MESSAGE_TEXT > ; 
<MESSAGE_TEXT > : : = < CHAR_STRING> 

f 

(b)  Example 

MESSAGE  #6:  ’(C)  DEFECTIVE', 

'5.0  MHZ  STD.  OUT  OF  (P)  TOLERANCE'; 


a character  string,  after  the  optional  keyword  TEXT 
and  equal  sign.  Thus  the  message  can  be  identified 
by  the  label  or  its  synonym. 


In  the  message  text,  the  following  four  special 
items  may  appear  to  indicate  the  locations  where  some 
actual  parameters  will  be  inserted. 

1,  A parenthesized  C,  (C)  , which  indicates  that, 
the  whole  set  of  affected  components  in  the 
referencing  diagnosis  will  be  inserted  literally  here. 

2,  C and  an  unsigned  integer  i enclosed  in 
parentheses  (Ci)  , indicating  that  the  i-th  affected 
component  will  be  inserted  in  this  position. 

3.  A parenthesized  P,  (P) , which  indicates  that 
the  whole  set  of  other-parameters  in  the  referencing 
diagnosis  will  be  inserted  here. 

4.  P and  an  unsigned  integer  i enclosed  in 
parentheses,  (Pi),  indicating  that  the  i-th  item  of 
the  other-parameters  will  be  inserted  here. 

Figure  3.16(b)  illustrates  an  example  of  message 
specification.  The  affected  components  and  other 
parameters  are  to  be  inserted  in  the  message  text  as 
indicated  by  (C)  and  (P)  respectively.  Therefore,  if 
AMPL_T0L ( STD_5MHZ_FRE0)  is  the  affected  component  and 
if  'AMPL'  is  the  other  parameter  (as  illustrated 


in  Fi(?ure  3.15),  then  the  resulting  message  text  will 
be  as  follows : 

AMPL_TOL (STD_5MHZ_FREQ)  DEFECTIVE 
5.0  MHZ  STD.  OUT  OF  AMPL  TOLERA.MCE. 

This  concludes  the  description  of  the  NOPAL 
language.  For  more  illustrative  examples,  the  reader 
is  referred  to  the  separate  documentation  [CHE  76]  by 
Mr.  Che  and  this  author. 

3.4  The  OPAL  Language 

OPAL  (Operational  Performance  Analysis  Language) 
is  a high-level,  procedural  test  language  in  which  one 
can  program  tests  for  a variety  of  devices  - electronic, 
mechanical,  hydraulic,  optical,  etc.  The  tests  for 
units  under  test  (UUT)  are  designed  to  be  run  on 
various  configuration  of  automatic  test  equipments 
(ATE).  Its  design  is  based  upon  the  language  contracts 
and  concepts  derived  from  the  existing  test  languages 
such  as  ATLAS,  GOAL,  and  CTL  [ARI  73,  NAS  73,  WAR  74], 
and  the  general  purpose  high-level  programming  languages 
such  as  FORTRAN,  ALGOL  and  PL/1. 

The  definition,  syntax,  and  semantics  of  the  OPAL 
language  are  documented  in  [FRA  76  ].  Since  some 
minor  changes  of,  and  additions  to,  this  language  have 
been  underway,  another  more  recent,  but  unedited 
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documentation  may  be  referred  to  for  the  updated 
features  [FRA  77  ]. 


Section  3.4.1  summarizes  the  basic  lexical  con- 
structs of  OPAL.  Section  3.4.2  gives  an  overview 
of  an  OPAL  program  and  various  types  of  OPAL  state- 
ments . 

3.4.1  Fundamental  Constructs  of  OPAL 

The  basic  lexical  constructs  or  components  such 
as  constants,  operators,  and  names  which  are  used  to 
form  higher  level  OPAL  statements  and  program  are 
summarized  in  the  following  paragraphs. 

The  twenty-six  letters . ten  digits , break  sign 
(-) , blank  and  other  special  characters  such  as  +,  -, 
and  $ form  the  OPAL  cha  rac t er  set. 

For  documentation  purpose,  comments  may  be 
included  between  statements.  A comment  is  sequence  of 
characters  which  begins  with  //,  and  ends  with  another  ' 
//  or  end-of-line  of  input. 

Some  punctuation  marks  such  as  comma,  parentheses. 


colon  and  dollar  sign  are  used  to  separate  one  language 
construct  from  another.  Note  that  a dollar  sign  (S) 


is  used  as  statement  end-marker. 


NOPAL  constants  include  integer  . real^  Boolean 


(i.e.,  TRUE  and  FALSE),  character-string.  and  b i t - 


s t ring  constants.  String  constants  are  enclosed  in 


single  quotes. 


Four  types  of  bit-string  constants 
are  supported:  Binary . Octal.  Hexadecimal . or  Binary 
coded-decimal.  Note  that  in  a character  string,  a 
single  quote  and  an  exclamation  point  must  be 
represented  as  and  I I respectively.  Some  editing 
characters  such  as  tab,  page,  and  space  may  appear 
in  a character  string. 

OPAL  uses  five  arithmetic  operators  (+,  -,  *, 

/,  and  **) , six  relational  operators  («,  #«,  < ,>,  <■ , 

and  >*),  five  logical  operators  (AND,  OR,  NOT,  and  XOR) , 
two  rotation  operators  (ROTATE_LEFT  and  ROTATE_RIGHT) , 
and  four  shift  operators  ( logi cal /ar i t hme t ic  shift 
left/ right) . 

OPAL  identifiers  (or  names)  are  strings  of  letters^ 
digits  and  break  characters  which  must  begin  with  a 
letter.  A name  is  used  to  identify  some  construct  in 
a program. 

Reserved- words  are  identifiers  having  a predefined 
meaning  in  OPAL.  They  include  verbs  such  as  SET  and 
APPLY,  keywords  such  as  BY  and  RESULT,  built-in- 
functions  such  as  ABS  and  MAX,  units  such  as  AMP  and 
VOLT,  nouns  such  as  AC  and  DC,  and  mod i f ie rs  such  as 
CURRENT  and  VOLTAGE.  A unit  is  an  OPAL  identifier 
used  to  name  a physical  unit  of  measure  (which  is 
equivalent  to  NOPAL's  dimension).  A noun  and  a modi- 


fier are  both  Identifiers  which  are  used  to  name. 


respectively,  a class  of  measureable  physical 
characteristics  and  a particular  one. 

A varlab le  is  an  OPAL  name  that  represents  a 
data  Item  which  can  take  on  different  values  durin^^ 
the  execution  of  a program. 

Finally,  an  OPAL  expression  is  either  a constant, 
a variable,  a function  call,  or  a combination  of 
these  and  operators  that  evaluates  to  a value.  The 
value  of  an  expression  may  be  real,  integer,  boolean, 
bit-string,  or  character-string. 

3.4.2  OPAL  Program  and  Statements 

An  OPAL  program  is  an  OP\L  text  which  describes 
a complete  test  procedure  for  a given  UUT,  including 
the  data  transfer  between  the  computer  and  the  outside 
world.  The  first  part  of  an  OPAL  program  names  and 
describes  the  characteristics  of  the  ATE  which  is 
assumed  to  be  available,  the  UUT  test  points,  and  the 
variable's  and  procedures  which  are  global  to  the 
entire  test  program.  The  second  part  is  a set  of 
executable  program  segments,  call  b locks . that  consist 
of  series  of  smaller  procedures. 

Formally,  an  OPAL  program  is  a collection  of  OPAL 
statements  enclosed  by  a program  header  and  a program 
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terminator,  as  shown  in  Figure  3.17.  An  optional 
program  name  may  be  given  in  the  program  header 
and  terminator.  The  first  part  of  the  program  body, 
called  main-descriptive  section,  consists  of 
descriptive  statements . Specifically  it  must  contain: 
(1)  all  REQUIRE  statements,  (2)  all  SPECIFY  statements 
and  (3)  the  DECLARE,  DEFINE,  PARTITION,  COMMON  and 
REFERENCE  statements  which  are  used  to  describe  all 
the  variables  and  procedures  that  are  global  to  the 
entire  OPAL  program.  The  remaining  part  of  the  program 
body  is  set  of  executable  statements  contained  in 
blocks.  Each  block  may  include  all  local  descriptive 
statements  (i.e.,  except  REQUIRE,  SPECIFY,  REFERENCE 
and  COflMON)  . Blocks  may  be  nested  within  blocks. 

A sample  OPAL  program  is  shown  in  Figure  3.18. 

Sections  3. 4. 2.1  and  3. 4. 2. 2 briefly  describe 
all  the  descriptive  and  executable  statements 
respectively. 

3. 4. 2.1  Descriptive  Statements  of  OPAL 

Descriptive  statements  are  used  to  name  and 
describe  variables,  procedures,  virtual  resources, 
and  UUT  test  points.  All  the  names  used  in  an  OPAL 
program  must  be  either  reserved-words,  or  statement 
labels,  or  described  in  a descriptive  statement.  The 
seven  descriptive  statements  are  summarized  below. 
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< OPAL_program  >«:■ 

BEGIN  OPAL  PROGRAM  [ < program_naine  >]$ 

[ < descriptive_stmt  >]* 

[ < executable_strat  >]* 

END  OPAL  PROGRAM  [ < pr ogram_name  >]$ 

< descrip tive_s tmt  >::»<  declare_s tmt  > 

I < define_stmt  >|  < partition_stint  > 

I < common_stmt  >|  < reference_stmt  > 

I < requl re_s tmt> I < speclfy_stmt  > 

< execu  t ab  le_s  tmt  >::«■<  ca  Icula t ion_s  tmt  > 

I < input_output_stmt>  | < f low_control_stmt  > 
1 < subroutine_control_stmt>  | < tasking_s tmt> 
I < Interrup t_s tmt  >|  < testing_stmt  > 


FIGURE  3.17  OVERALL  STRUCTURE  OF  AN  OPAL  PROGRAM 


BEGIN  OPAL  PROGRAM  DUMMY  $ 

//  DUMMY  TESTS  $ 

REQUIRE  . . . 

SPECIFY.  . . 

REFERENCE.  . . 

DECLARE  . . . 

DEFINE  . . • 

LI:  BEGIN_BLOCK  BLK1$ 

DEFINE  ...  //  LOCAL  ROUTINES 
DECLARE  ...II  LOCAL  VARIABLES 
APPLY  . . . 

DELAY  . . . 

READ 

SET  X « . . . 

BEGIN_BLOCK  BLK2$ 

END  BLK2$ 

END  BLK1$ 

END  OPAL  PROGRAM  DUMMY$ 


FIGURE  3.18  EXAMPLE  OF  OPAL  PROGRAM 
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‘(1)  A DECLARE  statement 


names  and  describes  the 


properties  of  OPAL  variables.  A variable  must  be  given 
one  of  the  five  modes:  Integer,  Real,  Boolean' 
Character-string,  or  Bit-string.  It  may  be  declared 
as  an  array  with  upper  and  lower  bounds  for  each 
dimension.  A variable  may  also  be  associated  with  a 
unit,  and/or  initialized  to  some  value. 

(2)  A DEFINE  statement  is  used  to  give  the  pro- 
perties and  definition  of  a procedure : either  a 
function,  a subroutine,  an  interrupt,  or  a task.  A 
f unc t ion  is  a procedure  which  returns  a single  value 
when  the  function  is  invoked  in  an  expression  by  the 
use  of  the  function-name  followed  by  the  parenthesized 
actual  arguments.  Subrout ines  are  procedures  which  may 
have  input  and  output  parameters.  They  are  invoked  by 
the  use  of  a CALL  or  TABLE  statement.  A subroutine, 
does  not  return  a value  as  a function  does,  but  it  may 
change  the  values  of  some  output  parameters.  Interrupts 
are  subprograms  which  check  for  the  occurrence  of 
critical  conditions  and  define  the  corresponding  actions. 
A task  is  a procedure  which  can  be  carried  out  in 
parallel  with  the  invoking  program  segment.  It  may 
include  input  and  output  parameters,  and  is  invoked  by 


an  ACTIVATE  statement. 


i- 


(3)  A PARTITION  statement  desciibes  a set  of 
range-names,  associated  with  ranges  of  values,  that 
a variable  can  have.  Range-names  are  used  in  TABLE 
statements,  or  IS  expressions  (which  yield  TRUE  or 
FALSE  depending  on  whether  expressions  are  in  the 
given  ranges)^  e. g. , 

PARTITION  X AS  LO  < - 3 < NOM  <8  < HI  $ 

(4)  A COMMON  statement  defines  those  variables 
which  are  shared  between  two  OPAL  programs.  The 
statement  must  appear  in  the  main-descriptive  sections 
of  the  programs  which  use  these  variables. 

(5)  A REFERENCE  s t at emen t identifies  the  program 
segments  or  files  which  are  described  external  to  the 
OPAL  program,  but  are  used  within  the  program  being 
processed.  This  is  intended  to  facilitate  the  use  of 
program  libraries  or  independent  modules. 

(6)  A REQUIRE  statement  is  used  to  name  and 
describe  the  properties  of  the  virtual  resources  needed 
to  perform  the  test  of  a UUT , and  assumed  to  be 
available.  Basically,  it  includes  the  name  and  type 
(source,  sensor,  load,  clock,  input  device,  or  output 
device)  of  each  virtual  resource,  and  optionally  the 
specifications  of  limitations,  accuracies,  and 
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connection  points.  It  must  be  in  the  main-descriptive 
section  of  an  OPAL  program*,  e.g., 

REQUIRE  ACS  AC  VOLTAGE  SOURCE 

WITH  0 AMP  < - CURRENT_AV  < - 10  AMP  +-  5PC, 
-10  VOLT  <»•  VOLTAGE_AV  <«  10  VOLT 

if 

CNX  HI,  LOS 

(7)  A SPECIFY  statement  names  the  test  points 
on  a UUT,  and  optionally  imposes  the  constraints  on 
them.  A UUT  is  modelled  as  a set  of  test-points  by 
using  these  SPECIFY  statements  in  the  main-descriptive 
section  of  the  program. 

Example:  SPECIFY  TPl,  TP2,  TP3$ 

3.4. 2. 2 Executable  Statements  of  OPAL 

An  executable  statement  describes  some  activity 
that  the  programmer  wishes  the  ATE  computer  to  perform. 
All  the  statements  which  are  referenced  elsewhere  must 
be  labelled  by  preceding  each  statement  with  an 
identifier,  called  label , followed  by  a colon  (:).  A 
labelled  statement  internal  to  a procedure  or  block 
cannot  be  referenced  by  any  statement  outside  the  pro- 
cedure or  block.  As  shown  in  Figure  3.17,  the  execut- 
able statements  are  grouped  into  seven  types,  which  are 
briefly  described  in  the  following  paragraphs. 


(1)  SET  statement  calculates  the  expression  on  the 


resultant  value  to  the  variable  on  the  left-hand  side. 
Example : 

SET  C - SQRT(A*A  + B*B)  VOLTS 

(2)  Input-output  statements  consist  of  an 
OUTPUT  statement  which  causes  a transfer  of  data  to 
an  output  device,  and  INPUT  statement  which  causes  a 
transfer  of  data  from  an  input  resource.  Optionally, 
both  statements  may  include  a format  expression. 

(3)  Flow-of-control  statements  are  used  to 
control  the  execution  sequence  of  events  through  an 
OPAL  program. 

IF  statement  causes  execution  one  of  the  two 
groups  of  statements  depending  on  the  value  of  a 
condition,  using  the  conventional  IF_THEN_ELSE 
construe  t . 

REPEAT  statement  causes  repetitive  execution  of 
a sequence  of  statements  until  a termination  condition 
has  been  satisfied. 

LEAVE  statement  causes  the  sequential  execution 
of  a IF,  REPEAT,  ESCAPE,  DO,  or  TABLE  statement  to 
stop,  and  then  to  resume  execution  at  the  next  state- 
ment following  the  indicated  construct. 

CYCLE  statement  causes  sequential  execution  of  a 
REPEAT  statement  to  stop,  and  to  resume  at  the  cycle 
point  of  the  REPEAT  statement. 


GOTO  statement  causes  to  transfer  unconditionally  to  the 


designated  statement, 

TABLE  statement  Implements  a decision  table  or  a two- 
dimensional  case  statement,  by  selecting  a set  of  actions  from 
several  alternatives  based  on  a set  of  conditions;  e.g.. 


TABLE 

T 

V; 

BROKEN_FAN 

HI 

LO; 

DEFECTIVE  PUMP 

LO 

HI; 

END  TABLE$ 

DELAY  statement  delays  the  execution  of  next  statement  for 
either  a given  time  or  until  manual  Intervention. 

INCLUDE  statement  causes  the  text  of  the  named  external 
program  segment  to  be  incorporated  in  line  into  the  program. 

BEGIN  BLOCK  statement  delimits  a block  of  OPAL  statements, 
which  may  contain  local  descriptions  other  than  COMMON,  REFER- 
ENCE, REQUIRE,  or  SPECIFY  statements. 

CHAIN  statement  causes  linking  of  the  current  OPAL  program 
to  the  named  OPAL  object  program,  with  optional  starting 
location  of  execution, 

(4)  Subroutine-control  statements  are  used  to  manage  the 
execution  of  subroutine  procedures: 

CALL  statement  causes  the  named  subroutine  to  be  invoked, 
possibly  with  arguments  to  be  passed  to  the  corresponding 
parameters . 

RETURN  statement  returns  control  to  the  procedure  that 


called  the  subroutine. 


r 


ESCAPE  statement  returns  control  to  the  escape  action 


contained  In  the  current  CALL  statement  when  an  abnormal  condi- 
tion has  occurred  In  the  execution  of  the  subroutine. 

(5)  Two  tasking  statements  are  used  in  managing  task 
procedures: 

ACTIVATE  statement  initiates  execution  of  the  named  task 
in  parallel  with  the  current  procedure. 

TERMINATE  statement  causes  execution  of  the  named  task 
to  stop . 

(6)  Two  Interrupt  statements  are  used  to  manage 
execution  of  Interrupt  procedures: 

ENABLE  statement  assigns  a priority  to  an  interrupt  and 

causes  the  interrupt  condition  to  be  checked  until  a DISABLE 

■) 

statement  is  executed. 

DISABLE  statement  suppresses  the  detection  and  processing 
' » 

of  the  named  interrupt. 

(7)  Testing  statements  are  used  to  perform  tests  on  the 
UUT:  *" 

START  statement  causes  a time  reference  point  to  be 
established . 

CHANGE  statement  modifies  the  setting  of  a virtual  resource. 
APPLY  statement  causes  a resource  with  Indicated  limita- 
tions to  be  connected  to  a test-place;  e.g., 

APPLY  ACS  WITH  VOLTAGE  = 7 VOLTS,  +-10  PC 
AT  HI  = PI,  LO  = P2$ 


A 
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MEASURE  statement  causes  a characteristic  of  the  UUT 
to  be  measuredj  e.g., 

MEASURE  AC  VOLTAGE  IN  VOLT  INTO  X USING  ACS 
WITH  VOLTAGE  <=  .7  VOLT  AT  HI  = P1,  LO=P2’? 

SETUP  statement  causes  a named  resource  to  be 
initialized  in  a specified  way. 

CONNECT  statement  connects  a resource  to  the  UUT  at 
the  specified  UUT  test-points. 

DISCONNECT  statement  eliminates  the  interconnection 
between  a resource  and  the  UUT  test-points. 

CLOSE  statement  initiates  or  gates  a resource  to  the 

UUT. 

OPEN  statement  does  the  opposite  of  CLOSE,  namely, 
turns  off  or  inhibits  the  function  of  a resource. 

READ  statement  causes  the  current  value  of  a UUT 
characteristic  to  be  read  and  stored. 

REMOVE  statement  causes  a resource  to  be  opened, 
disconnected,  and  reset  to  its  quiescent  state. 

MONITOR  statement  combines  the  functions  of  the 
APPLY,  READ,  and  OUTPUT  statements  which  are  to  be 
re-peated  until  manual  intervention. 
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CHAPTER  A 

THE  NOPAL  PROCESSOR 


4 . 1 Overv lew 

This  chapter  covers  the  overall  description  of 
the  NOPAL  Processor.  As  presented  in  Chapter  3,  the 
NOPAL  language  is  a higher-level  non-procedural  pro- 
gramming language  in  which  one  can  specify  tests  on 
various  classes  of  units-under-test  (UUT)  under  a 
computer-controlled  automatic  test  equipment  (ATE) . 

The  NOPAL  processor  (hereafter  called  the  Processor) 
is  designed  to  automate  the  program  design,  coding,  and 
debugging  phases  of  program  development  based  on  test 
specifications  written  in  NOPAL  language.  A collection 
of  NOPAL  statements  describing  a functional  module  is 
referred  to  as  a specification . A complete  description, 
in  NOPAL,  of  the  tests  desired  for  a given  UUT  under  a 
given  "virtual"  ATE  is  referred  to  as  a NOPAL  specifi- 
cation. A NOPAL  specification  consists  of  test -module  s - 
specif Icat ion , UUT -specification,  and  AT E-specification. 

A t es t -modules-spe c if i c a t i on  is  the  core  of  a NOPAL 
specification.  It  describes  the  set  of  desired  tests 
by  specifying  the  stimuli  to  be  applied,  measurements 
to  be  performed,  logics  to  be  used  to  select  diagnoses, 
and  the  corresponding  diagnoses  and  messages.  A UUT- 
spec if icat ion  identifies:  1)  potential  component 


failures  and  2)  the  connecting  points  of  the  UUT . An 
ATE-specif ication  defines:  1)  the  ATE  functions,  such 
as  stimuli,  measurements,  or  special  computational 
capabilities  and  2)  ATE  in t er-connec t ing  points.  As 
shown  in  Figure  4.1,  the  Processor  takes  a NOPAL  specifi- 
cation as  input,  and  then  performs  analyses  (syntax, 
semantics,  completeness,  consistency,  ambiguity,  etc.), 
test-modules  sequencing  (intra-  and  in  ter- 1 es t -modu le ) 
and  code  generation.  It  finally  produces  as  output  a 
procedural  object  test  program  (written  in  OPAL, 
Operational  Performance  Analysis  Language,  as  explained 
in  Chapter  3),  together  with  various  user  reports  such 
as  reformatted  specification  listing,  cross-references, 
sequencing  flowchart,  and  error/warning  messages.  All 
of  these  output  reports  will  be  fully  described  in  later 
chapters . 

The  processor  performs  the  translation  from  source 
language  (here  NOPAL)  to  target  language  (here  OPAL) 
as  other  conventional  compilers  do.  Two  other  functions 
of  the  Processor  are  important.  It  processes  a non- 
procedural source  specification  and  then  generates  a 
complete  procedural  target  program,  based  on  an  appli- 
cation  of  directed-graph  theory.  The  Processor  provides 
better  system-user  interaction  by  sending  to  the  user 
proper  warnings/errors  indicating  necessary  changes  or 
cd’i.tions  to  the  submitted  NOPAL  specification. 


Processing  of  NOPAL  specification  by  the  Processor 
consists  of  three  major  phases  shown  in  Figure  4.2,  which 
is  a refinement  of  Figure  4.1.  The  three  phases  depicted 
in  Figure  4.2  is  briefly  discussed  in  Sections  4.2,  4.3 
and  4.4,  and  will  be  presented  in  detail  in  the  following 
Chapters  5,  6 and  7 respectively. 

4.2  Phase  I:  Syntax  and  Statement  Analysis  of  NOPAL 

Specification 

In  this  phase  each  statement  of  the  NOPAL  specifi- 
cation is  analyzed  to  find  syntactic  and  some  local 
semantic  errors.  Two  reports,  specification  source 
listing  and  syntax  errors /warnings , are  produced.  These 
tasks  are  performed  by  a submonitor,  called  Syntax 
Analysis  Program  (SAP),  which  is  itself  generated  auto- 
matically by  a meta-processor  called  Syntax  Analyls  Pro- 
gram Generator  (SAPG).  The  input  to  SAPG  is  the  formal 
syntax  rules  of  the  NOPAL  language  and  calls  on  some 
routines  (written  in  PL/I) . Changes  to  the  syntax 
of  NOPAL  during  development  and/or  in  the  future  can 
thereby  be  easily  made.  Note  that  SAPG  is  no  longer  used 
once  SAP  is  generated.  As  indicated,  SAP  consists  also 
of  routines  such  as  lexical  analyzer,  error-stacker,  and 
s to  re / r e t r ieve  package. 
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PHASE  I: 


PHASE  II: 


PHASE  III: 


Figure  4,2  Major  Phases  of  NOPAL  Processor 


Another  task  of  this  phase  is  to  store  the  NOPAL 


statements  in  an  associative  memory  (stimulated  on  main 
memory)  for  ease  in  subsequent  retrieval  and  modifi- 
cation of  the  NOPAL  specification  during  later  stages 
of  analysis  and  processing.  The  associative  memory  is 
also  used  for  generating  three  reports.  A conventional 
cross-reference-and-attributes  report  is  provided  for 
the  user,  together  with  some  warnings /error s and  suggested 
corrections.  A completely  reorganized,  easy  to  read 
source  listing  of  the  NOPAL  specification  is  produced. 

The  third  report  is  a summary  cross-references  of  test- 
modules,  UUT , and  ATE  specifications. 

This  phase  of  syntax  and  statement  analysis  is  pre- 
sented in  detail  in  Chapter  5. 

4.3  Phase  II:  Specification  Analysis  And  Sequence 

Determination 

This  phase  of  the  Processor  determines  precedence 
relationships  based  on  analysis  of  the  NOPAL  specifi- 
cation. It  also  ascertains  the  consistency,  complete- 
ness, and  unambiguity  of  the  statements.  As  the  non- 
proceduralness of  NOPAL  implies,  the  order  of  the  state- 
ments provided  by  the  user  is  of  no  consequence.  However, 
various  components  of  the  statements  are  analyzed  to 
determine  precedence  relationships.  These  relationships 
are  then  used  to  form  a directed  graph,  represented  by  a 
precedence  matrix.  Each  node  of  the  graph  represents  a data 
(variable)  name,  a diagnosis,  or  a statement  (or  a test 
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module  consisting  of  a group  of  statements).  Each  directed 
gj-S-g  denotes  a certain  type  of  precedence  relationship,  having 
a related  priority.  Based  on  the  graph,  it  can  be  determined 
whether  the  test  specifications  are  complete,  consistent,  and/ 
or  unambiguous.  Also,  a user  report  is  produced  containing 
error/warning  messages,  assumptions  made  by  the  Processors, 
and/or  appropriate  actions  to  be  taken  by  the  user. 

The  next  task  in  this  phase  is  to  determine  the 
execution  sequence  of  all  events  implied  by  the  specifi- 
cation, based  on  the  directed  graph.  The  result  of  this 
task  is  a set  of  data  structures  representing  a correct 
sequence  of  processes  and  flow  of  events,  assigned  to 
levels  and  sequenced  in  the  order  of  execution.  A flow- 
chart-like report  is  produced  for  the  user. 

Note  that  there  are  two  'sub-phases  of  the  above 
mentioned  analysis  and  sequencing:  intra-test -module 

and  inter-test -module.  The  former  deals  with  the 
analysis,  and  sequencing  of  a given  test  module,  by 
examining  the  conjunctions,  assertions,  and  diagnoses.  The 
latter  concerns  the  analysis  and  sequencing  of  the  collection 
of  test  modules  in  a given  NOPAL  specification,  considering 
each  test  module  as  an  integral  unit. 

Detailed  description  of  this  phase  is  covered  in 
Chapter  6. 

4.4  Phase  III:  Code  Generation 

In  this  phase  the  object  OPAL  program  is  generated. 

First,  global  variables  are  declared  and  properly 
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initialized.  Second,  an  OPAL  subroutine  is  defined  for  every 
test  module  specified  by  the  user;  the  code  for  a test-module 
subroutine  is  generated  immediately  after  the  internal 
sequencing  of  the  test  module  has  been  completed  successfully. 
Third,  a subroutine  is  also  produced  for  every  operator 
message  defined  in  NOPAL  specification.  Lastly,  the  OPAL  code 
for  properly  invoking  test-module  routines  and  for  inserting 
necessary  control  logics  are  generated.  This  last  step  is 
begun  after  the  inter-test-module  (i.e.,  external)  sequencing 
of  the  specification  has  been  successfully  done. 

The  product  of  this  phase  is  an  OPAL  test  program  in 
accordance  with  the  NOPAL  specification  provided  by  the  user 
for  testing  the  UUT.  This  OPAL  program  may  be  augmented  by  a 
library  of  OPAL  routines,  if  the  user  so  desires  and  supplies 
it.  Any  routine  (NOPAL  function)  which  is  used  in  the  NOPAL 
specification  and  whose  OPAL  code  is  not  supplied  at  this 
stage  by  the  user  is  expected  to  be  resolved  later  at  OPAL 
compile  time,  or  even  at  run  time.  The  complete  OPAL  program 
is  then  ready  for  compilation  and  execution  (actual  testing 
of  the  UUT)  in  a given  ATE  system. 

Chapter  7 describes  Phase  III  in  more  detail. 


CHAPTER  5 


SYNTAX  ANALYSIS  AND  ASSOCIATIVE  MEMORY 

5.1  INTRODUCTION 

The  first  phase  of  the  NOPAL  Processor  performs  syntax  and  local 
semantic  analysis  of  specification  statements.  At  the  end  of  the  ana- 
lysis,  each  NOPAL  statement  is  encoded  and  stored  in  simulated  associa- 
tive memory  for  ease  in  further  processing.  As  shown  in  Figure  5.1, 
the  first  phase  consists  of  a Syntax  Analysis  Program  (SAP).  SAP  it- 
self is  generated  automatically  by  a meta-processor.  Syntax  Analysis 
Program  Generation  (.SAPG),  by  inputting  the  formal  specification  of  the 
NOPAL  language  in  a meta-language.  Extended  Backus  Normal  Form  with 
Subroutine  Calls  (EBNF/WSC). 

Section  5.2  discusses  the  EBNF/WSC,  SAPG,  and  SAP  in  more  detail. 

SAP  incorporates  six  types  of  supporting  routines  which  must 
be  composed  manually:  Lexical  Analyzer,  Error  Stacking,  Recognizer, 
Encoding/Saving/Storing/,  Semantics  Checking  and  Housekeeping.  These 
are  covered  in  Section  5.3. 

At  the  end  of  each  NOPAL  statement,  a storing  routine  is  invoked 
to  store  the  statement  in  the  simulated  associative  memory  using  a 
store/retrieve  package.  The  store/retrieve  package  is  presented  in 
Section  5.4. 

Section  5.5  describes  the  processing  of  two  NOPAL  specification 
reports  and  a syntax  error  report  by  SAP.  A source  specification 
report  is  produced  by  the  lexical  analyzer  as  a by-product.  It  is  a 
listing  of  the  NOPAL  statements  as  entered  by  the  user.  Another  refor- 
matted specification  report  is  generated  by  retrieving  the  statements 
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t, 

FIGURE  5.1 


SAP  WITH  SAPG  AND  OUTcPUTS 


from  the  associative  memory.  This  is  a reformatted,  reorganized  NOPAL 
specification  listing  for  easy  readability.  The  syntax  error  report 
contains  error  and/or  warning  messages  generated  by  SAP. 

Finally,  Section  5.6  presents  the  part  of  the  system  that  generates 
a set  of  cross  reference  reports,  which  are  summarized  in  Table  5.1. 

5.2  E3NF/WSC,  SAPG,  and  SAP. 

The  Syntax  Analysis  Program  (SAP)  for  processing  the  NOPAL  state- 
ments is  generated  by  the  Syntax  Analysis  Program  Generator  (SAPG). 

4 

The  input  to  SAPG  is  a specification  of  the  NOPAL  language  in  a meta- 
language Extended  Backus  Normal  Form  with  Subroutine  Calls  (EBNF/WSC). 

SAPG  and  EBNF/WSC  were  developed  at  the  University  of  Pennsylvania 
by  the  Data  Definition  Language  Project  [RAM  73  and  FRE  72].  A brief 
review  of  SAPG  and  EBNF/WSC  is  given  in  the  following  sections. 

5.2.1  SPECIFICATION  OF  NOPAL  USING  EBNF/WSC  and  SAPG 

The  EBNF/WSC  includes  and  extends  the  concepts  of  the  conventional 
Backus  Normal  Form  (BNF).  The  BNF  itself  is  a language  consisting  of 
statements  (production  rules)  which  describe  the  syntax  of  formal 
languages  (here  NOPAL).  BNF  uses  four  meta-1 inguistic  characters  <,>, 
and  I . Sequences  of  characters  enclosed  in  angle-brackets 
are  called  non-terminals,  and  denote  names  of  syntactic  units  and  for 
which  substitutions  may  be  made.  Sequences  of  characters  not  enclosed 
in  angle-brackets  ai"e  called  terminals , which  represent  keywords  or 
characters  in  NOPAL.  Each  production  rule  in  the  BNF  is  of  the  form 
"L  ::=  R" . L is  a non-terminal  symbol  and  R is  one  or  more  alternative 
sequences  of  terminal  or  non-terminal  symbols  that  can  be  substituted 
for  L.  The  alternatives  are  separated  by  the  meta-l inguistic  symbol 

tt  fi 

1 1 1 


TABLE  5.1  CROSS  REFERENCE  REPORTS 


Report  Name  of  Report  Name  of  Entity 
Number  Cross  Referen- 


XREF-ATTR 


DIAG-TEST 


Diagnosis 


MESS-DIAG-TEST  Operator  mes- 
sage 


COMP-DIAG-TEST  Affected 

component 


UUT.PT-TEST-  UUT  connecting 

ATE.PT  point 


Name  of  Entities 
Cross  Referenced 
with 


ource  statement 
numbers , attri- 
butes 


Test  modules 


Diagnoses , test 
modules 


Diagnoses , test 
modules 


Test  modules , 
ATE  connecting 
points 


6 


FUNC-TEST 


ATE  function 


Test  modu 1 e s 


To  facilitate  language  description,  BNF  was  extended  to  EBNF  with 
two  meta-1 inguistic  symbols:  [ ] representing  optionality  and  [ ]* 
representing  repetition  of  zero  or  more  times.  Because  of  unavailabi- 
lity of  the  square  brackets  [ ] in  regular  keypunches,  the  left  bracket 
[ is  replaced  by  &-0.  multi -punch  immediately  followed  double  quote  " , 
and  the  right  bracket  ] by  double  quote  immediately  followed  by  &-0 
multi-punch.  Note  that  in  the  computer  printouts  the  &-0  multi-punch 
becomes  blank,  hence  the  two  brackets  appear  as  double  quotes. 

A description  of  the  NOPAL  language  using  EBNF,  without  subroutine  * 

calls,  has  been 'presented  in  Figure  3.1.  The  EBNF,  like  BNF,  is  suf- 
ficient to  describe  the  syntaj(  of  the  NOPAL  language;  it  is  not  capa- 
ble of  describing  the  semantics  of  the  language.  Therefore,  EBNF  was 
expanded  to  allow  subroutine  names  to  be  embedded  within  it.  Hence 
the  name  "EBNF  with  Subroutine  Calls"  (EBNF/WSC)  was  adopted. 

The  EBNF/WSC  specification  of  NOPAL  constitutes  the  input  to  SAPG. 

It  consists  of  the  syntax  specification  as  well  as  subroutine  names 
enclosed  in  slashes  The  embedded  subroutine  name  indicates  need 

to  the  respective  subroutine  upon  successful  recognition  of  the  prece- 
ding syntactic  unit.  Thus,  these  subroutines,  incorporated  in  SAP, 
enable  checks  of  local  semantics.  They  produce  error  messages,  encode 
/save,  and  store  away  statements.  The  invocation  of  these  subroutines 
is  incorporated  in  the  automatically  generated  SAP.  The  sub-routines 
themselves  are  written  manually. 

The  specification  of  the  NOPAL  language  in  EBNF/WSC  is  shown  in 
Figure  5.2.  Unlike  the  human-oriented  EBNF  specification  presented 

113 

J 


r 


fO  oo  o »o  o pH  «-4  ^ 

h/>  ^ ^ ^ CH 


<M  o 00  ^ 

<M  ,-4  C4  (>|  (SI  <M 


^ fo  fo  K*.  m 1 


a\  o 
ro  ^ 


s 

V 

A 

s 

5i 

CO 

X 

O 

0. 

p4 

W 

X 

V> 

u 

« 

UJ 

u. 

< 

CD 

> 

u. 

s 

N. 

V 

"S 

1 

A 

A 

X 

i* 

2 

V 

2 

< 

V 

< 

e 

C 

V) 

A 

c: 

LJ 

< 

c. 

2 

< 

£ 

►- 

X 

O 

c. 

C 

M 

< 

Ui  A 

# 

A ec 

O 

e 

-I 

►- 

¥•  >s 

e 

Ul 

V N» 

< 

s 

2 

V 

1 

G£ 

A A 

u 

A 

U « 

V 

2 

V 

e a: 

•H 

£ 

< 

A 

C.  uJ 

u. 

c 

S 

D s 

</> 

U 

X c 

< 

O A 

C. 

V 

2J 

UJ  u 

u 

£ 

S ^ 

X 

c 

X 

L.' 

f x 

u 

M 

< 2 

u 

o 

c 

X 

X 

0. 

e 

V UJ 

£ 

o 

CO 

Gi 

►-  4 

c/l 

Q. 

£ 

N. 

V 

a. 

N. 

1 

A * 

V 

N.  3 

A 

X 

e s : 

£ 

o iS 

C 

N. 

< N.  A 

. < 

(C  « S 

V)  e 

O 

£ 

X 

V £ O 

e Q. 

s o 

Ul  2 
K V 


Li  A 

»-  s e: 

V A O 

c »- 


(/) 

X — 

u 


u.  < 

> V 
'S 


V 

2 s 


VI  V < 
S.  A V5 

X £ a 

W C£  X 


o •-• 

V9  I 

u c: 
o o 


tc  u 

£ 

V 

s 

CO 

% 

^ A 

*2 

UJ 

w 

Ul 

1- 

C->  V 

s 

ut  < 

< 

X 

u. 

nj 

22 

V 

k- 

z 

X, 

u* 

N*. 

►-  Uu 

V 

< 

> 

CO 

V o 

«< 

1 

V 

A UJ 

U. 

V V 

A 

CO 

X 

V 

u. 

3 

s 

2 

A 

X 

2 

A 

• 

CO 

2 

X 

U. 

• 

> 

2 U 

< 

Z 

o 

2 

CO  ^ 

X 

V N. 

O 

u 

V 

> 

3 

O < 

u 

z 

pm 

O 

£ 

u 

«H  «H 

M q: 

•H  V 

H- 

A 

s. 

U Ck. 

A 

X 

CO 

u 

£ 

e 

CO  CO 

►- 

4 

CO  L. 

U 

►- 

ec 

U.  1 

X* 

o 

u 

2 

V 

f-  CO 

< 

X X 

< 

V 

X > 

CO 

CO 

^ r 

X 

o 

1 

UJ 

* 

CO 

>S 

V 

UJ  u 

A 

U (0 

N 

2 

% CO 

\ < 

< 

c 

X 

X 

3 

1 

A 

ic  ec 

2; 

Z X 

O 

X z 

u 

£ 

V 

w 

2 

< < 

2 0. 

<r  w 

A 

u 

<*  u 

A J 

c 

< 

N. 

C9 

N.  >s 

U 

X 

V z 

O 

1 

CO  V £ O 

z 

z 

V A 

0. 

e 

V 

A A 

2 

Ul 

A < 

z 

u. 

e c 

< 

z 

a 

o 

►- 

Q 

CO 

a a 

V 

O 

1 

ec  N. 

1 

A 2 

> A 

Ui  s 

1 

r 

V 

pm 

2 

2 

£ 

V 

o o 

H* 

a. 

X 

UJ  A 

2 

Z « 

V J 

^ V 

N. 

. 1 

V 

3 

3 

I 1 

u 

X 

CS  -i 

O 

Ul  z 

A J 

1 V 

< 

A 

A Z 

(0 

2 

V 

C f- 

2 

Ui 

£ ^ 

M 

•-  u 

z < 2 a 

u 

X 

Z 

o 

s 

V 

o 

CO 

u 

ec 

V 

o u 

O 

V 

fiC 

3 < 

>— 

U.  CO 

c.  u 

< X 

u 

o 

U 

0. 

O Li  H- 

X 

< 3 

a 

3 

< 

2 U 

u 

V 

X 1 

U Ul 

o 

X 

f- 

u 

Ui 

•s. 

a 

or 

CO 

u 

V £ 

X 

V 

1 f 

2 

K V 

U 2 

^ c 

o 

c 

Ul  Ui 

II 

e 

>S 

N.  C 

X 

as 

s V 

Li 

O 2 

3 

2 CO 

1 O 

O 1- 

3 

>s 

u 

2 

•• 

Ui 

CC 

< 

< 

3 

N. 

A 

UJ  O 

U. 

u e 

X ^ 

c u 

V 

2 

X 

•• 

£ 

Ull 

N. 

V)  z 

>• 

V 

2 •-* 

V 

O 3 

^ ►- 

C CO 

2 

G 

< 

o 

•• 

flC 

11 

N.  O 

Li 

ac 

O f- 

•-  CO 

»-«  u 

V N. 

II 

o 

Ul 

A 

2 

Ui 

•• 

Li 

•« 

>s 

CO 

A 

A 

N it 

< 

z 

IH  U 

V Cd 

Z 2 

M 

•• 

Ul 

V 

2 

■s. 

►- 

•• 

X 

a.  1 

•• 

£ 

u 

CO  2 

II 

z 

< 3 u. 

•« 

•• 

V 

O 

2 

£ 

If 

o 

o 

M •• 

X 

2 D 

•• 

< 

V u. 

M II 

•• 

V 

•i^ 

•* 

A 

•• 

II 

1 — 

os 

< 

3 U. 

*• 

II  V 

V 

•• 

II 

»- 

ri 

V Z 2 A ••  •• 

It 

u 

o 

» 

z 

N V V 

••  M 

•• 

A 

•• 

< 

•• 

Ui  Xk 

Z — 

•• 

< 

O 

♦ 

A 

V 

•• 

II 

£ A 

V 

••  11 

1 U 

•• 

o 

Ui 

•• 

Lk 

< 

2 

mm  M 

A 

II 

II  •• 

o z 

z 

•• 

II  UJ 

Z A 

V 

V 

M O 

M 

• • 

••  •• 

A 

I o 

< 

• « 

u. 

— w It 

£ •“  A 

II 

••  pm 

11 

•m 

A •• 

•• 

r 

rr  k- 

c 

A 

M 

A 

»•  7 •• 

3 CO  to 

A 

•• 

••  ^ 

• • 

mm 

4 

Q 

G iJ 

X 

u 

ec 

•• 

2 2 2 

rr 

II 

II 

4 

•• 

Ui 

mm 

A 

Ul 

4 

z 

UJ  A 

u 

UJ 

t 

1 C ^ 

Z 

•• 

M 

1 

1 A 

A U 

W 

c. 

1 Z 

c. 

A 3 

C CJ  z 

X 

•• 

•• 

A I- 

A 

2 

2 H 

Ui  CO 

1 

11  1 

1 

£ C 

<o 

u. 

Z Ul  A 

u t ►- 

Ui 

A 

a 2 

A 

>- 

O 

C 2 

-J  3 

2 

••  2 

2 

mm 

1 

UJ  2 Z 

2 O CO 

1 

a 

o u 

z 

Cj 

M Ui 

O 4 

< 

••  4 

4 

C Ul 

[ -J 

I— 

O O Ui 

iD  2 1 

X 

A 

A 

o 

1 2 

o 

< 

H- 

1-  £ 

< ^ 

(iJ 

Ui 

1 UJ 

4 

2 

Ul  ^ 3 

M Cl 

►- 

£ 

2 

1 1-  c 

u- 

> 

CJ 

U 3 

M U 

2 Z 

C. 

UJ 

^ to  £ 

to  z < 

M 

Z 

O 

c 

c. 

u 

*m 

2 

2 e 

Z 1 

o 

A O 

o 

2 2 

O 

o 

2 2 3 2 I-  r 

z 

u 

pm 

Q 

3 X 

4 

Z 

3 

3 Z 

c u. 

o 

Z O 

o 

O C 

2 

fS 

« 3 2 

3 CO  u 

< 

CO 

< 

£ U 

U.  Ck 

u. 

u.  4 

> — 

X 

C X 

X 

U Ul 

1 ..  '' 

V 

V V V 

V V V 

V 

V 

V 

V 

V V 

V 

V 

V 

V V 

V V 

V 

V v 

V 

V V 

114 


# 


I <coNNrcTon_io> 

fCOMfll  CT0R.ID>  IJ=  /rDCni/<IOtNTlFICR>/CDESlO/ 
<DIKE»JSI0N>  :;=  /OlMHLr/ 


Ok  OkCMKi^tn  >0^0  r<*> 

'O  'Ot^p*'r^r^  loc^  r-  e^i 


i/k  >0  f-^ 

00  00  OOoO 


G 

u.  u. 

X 

X 

3 

1 

<0  <0 

G 

u 

A 

2 

“5  -3 

< 

1 

0 X 

0 U 

> 

X 

X 

0 

s 

M Q 

X X 

<0 

a 

»- 

C 

•• 

»-  2 

A A 

•1 

2 

X 

£ 

3 

2 

iJ  W 

X X 

u 

UJ 

G 

• 1 

A 

2 >- 

UJ  w 

X 

0 

h- 

< 

2 

Ui 

2 

X 

U/ 

3 £ 

1 1 

3 

X 

£ 

V 

0 

X c 

CO 

")  *- 

£ £ 

G 

A 

H 

A 

er 

.J 

2 

3 

Z CO 

M ^ 

U 

V 

co 

10 

2 

< 

►-  C 

UJ 

C 

C X 

A 

a a 

(/> 

s 

0 

X 

X 

X 

G 

.J 

G 

u 

z 

1 1 

G 

«« 

0 

2 

0 

A 

U 

> 

£ 

to 

V X 

A C X 

U Ul 

c 

A 

X 

G 

X 

2 

(0 

(/; 

►- 

M. 

£ 

^ 

2 2 

X 

u 

G 

1 

£ 

£ 

(/)  0 

CO 

X 

(O 

G 

X u. 

cj  ^ a. 

3 3 

CO 

< 

2 

1 

< 

M 

< 

A 

X 

I 

^ > 

z u •- 

U.  U. 

S A 

U4 

a 

0 

> 

(0 

X 

V 

C 

-5  < 

3 2 e 

V V 

A «J  s 

«•» 

3 G 

< 

A 

3 

it  < 

U 

X 

C 

2 3 

331- 

1*  oj  A 

A 

X 

. t 

X 

u- 

3 

2 

s 

u 

G 

(S 

H- 

0 ^ 

Z *3  <0  X X 

U G Z 

H’ 

G 

G 

0 

Q. 

UI 

CO 

< 

< 

< 

U CO 

0 2 X 

-J  ^ 

A 

2 < 0 

CO 

< 

CL 

* 

UJ 

CO 

V 

3 

3 

pm 

G 

X X 

u 0 

Ui  UJ 

2 

3 3^ 

a 

M 

<0 

X 

►- 

2 

X 

V 

X 

UJ 

1 

G 

U 

1 u « 

G G 

0 

3 1 ►- 

G 

c 

2 

c/) 

G 

UI 

CO 

2 

C3 

G 

••  * 

U-  1 

10  CO 

>«* 

2 to  U 

1 

X 

0 

A 

< 

« 

UJ 

0 

X 

c. 

< 

CO 

A 

C 

X 

U U S 

3 *3 

►- 

0 < 2 

UI 

CO 

U- 

V 

(O 

A 

2 lO 

K 

*■4 

X 

c9 

V 

Z s 

«J  ^ A 

U CJ 

U 

U U 3 

3 

» 

« 

G 

Q. 

2 

(0 

< 

u 

UJ 

A 

0 

< 

0 A 

X 0.  H- 

X X 

2 

1 £ 3 

G 

3 

X 

• • 

A 

< 

G 

si 

CO 

Z 

V 

A 

3 

^ z 

M £ U 

A A 

3 *-  1 Z 

<c 

s 

s 

to 

G 

<0 

X 

2 

1 

X 

CO 

CO 

< 

0 

>• 

G 

0 0 

e ^ «i 

Z 2 

3 

W £ 0 

A 

A 

V 

U G 

C 

u 

Ui  < 

< 

X 

M 

X c 

1 

u 

^ CO  G 0 0 

Z 

^ M U 

G 

£ 

£ 

CO  3 ►- 

1 

X 

X 

^ 0 

X ►- 

V V ^ 

M »i4 

0 

a.  1-  1 

< 

UI 

U 

X 

G (0  G 

>- 

a -j 

A 

G 

cd 

< 

3 

< 

G >-  ►- 

0 

M CO  Ui 

> 

u 

3 Q 

3 

3 

<0 

< 

£ 

< 

X 

G 

U 

< 

1 

2 A 

A ec 

w ^ 

< < 

1 oc  V «J 

V 

u 

U 

M 

<0 

u 

< 

G 

z 

CO 

CO 

C 

0 

U 

a < 

V 

UJ 

a 

1 

1 CO 

V 

0 

X 

< 

CO 

0 

G 

X 

CO 

3 

< 

mm 

c 

•! 

A A 

UJ  UJ 

.J 

V X c 

G 

• 

X 

U 

V 

X 

u 

< 

X 

< 

I ui  2 *0  c:  Of 

l u O S V V 

I z •-• 

' UJ  ^ V V 

d U /N  M 
U/  Z ”3  “3 
U.  3 UJ  Z Z 
LJ  ^ C O 
(T  2 a U U 

I O N. 

^ u o:  y\  /\ 

tj  I k-  X X 

< U.  V u w 

ffi  •-•  II 
■VV  V c t 
o II  M *•« 

z — o o 

13  II  II  - I I 


fi,  ^ 

Z U Ui  </) 

^ V5  £.  V 

«o  ^ < 

V UJ  <4  A 
r V ►- 
A C/3  G. 

14.  < U 

V3  U 

3 K A 

< s U ^ 

.J  W V Ul 

W C S 02 

I < < 

u.  «0  ^ 

X NN  S V 

U V 


O A C O ( 
U Z U O I 
X A A o V V 


< < C3  I GC 

to  ^ < u < 

s V e > 

X q:  c/)  V 

►-  < X — 

n OL  > 

II  ••  Ui  V 

••  ••  O U H 

^ X •«  •• 

Ui  tl  ••  •• 


< U * A U 
>Q  A O U 
V X S O 

•A  A Q.  IV 
s e:  X £ s 
u a u a: 

« ^ I o 

A u e X u 

£ M U H>  UJ  . 

U H-  OC  *^  > 

^ 2 CD  c:  < 

Lj  L.*  3 < a 
I C CO  V V 
flC  V X 

< V iO  A 
> X s G H- 
y/  w4  go: 

G CO  U 

uj  cd  </}  I 

» U tl  C CO 

U ••  < < I 

C ••  X V 

X 


I A C 
W (/)  V 


A O 
UJ  V 
CO 

X G 

2 < tl 

-i  •• 

c u •• 

CO  I 

3 U. 

J ^ A 

Ol  V Z 

X o 
II  ^ 
♦•  ^ 


A < 
C&  OC 
< w 

a o 

X A IV 
CO  U c s 
o UJ  z 
z a o 
o < 3 
< ^ W II 
M V Ui  •• 
C X •• 
X V 


«• 

^ M — 

A 

X •• 

< 

Z 

A 

II  — 

M 

A 

«« 

0 w — 

A 

A 

«J 

•• 

A 11 

II 

X A 

0 

22 

•• 

z 

II 

•• 

II 

iS 

II  0 2 U 

tl  z 

Ui 

UJ 

A 

A 

•1 

w •• 

•• 

5. 

*• 

•• 

•• 

•• 

< 

— G 3 2 tl 

— 0 

CJ 

G 

II 

UI 

►- 

•• 

to  •• 

•• 

G 1" 

X 

A lu 

•• 

•• 

mm 

A 

— 1 3 3 •• 

••  M 

< 

••  X 

0. 

to 

•• 

fci* 

II 

0 

fT 

UJ 

UI 

c 

5 

Z 2 3 — 

•M 

Ui 

mm  9>mpm 

•• 

m 

Ui 

1 

^ 0 

0 

1 

0 

0 0 z 

iJ 

G 

1 

•.  0 

I A 

A 

•• 

1 CO 

CO 

1 

A 

.J 

A uu  u 0 

A Z 

UJ 

10 

1 

1 

A 

Z 

z 

to 

< 

3 >- 

CO 

to 

Ul 

V 

< 

u 

^ IDA 

2 3 

u. 

< 

►- 

w 

Ut 

C 

C.  G C 

0 

< 

2 

2 G 

mm 

mm 

G a 2 

CJ 

u 0 ^ l>- 

0 3 

u 

Ui 

A < 

3 

u 

M 

M 

A 

1 

C 

mm  tJ 

to 

CO 

< 

0 c 

2 

Z Z U U UJ 

« Z 

ag 

£ 

»-  G 

G 

.J 

G G 

u 

u 

«• 

c <0 

0 

0 

-J 

a 

3 

3 3 ..J  U U 

►-  0 

1 

1 & < 

< < 

U U G 

2J 

2j 

3 

• to 

2 

z 

1 

t 

3 

3 3 a a G 

< u 

G 

Z 

UJ  .J 

•m 

mm 

1 (A 

UJ 

UI 

u 

G 

< 

CO  < 

iS 

IS 

IS  « 

•• 

2 

Z Z M £ *« 

•J  1 

U 

0 u 

G 

G 

G 0 

to 

to  to 

£ 

3 1 

< 

< 

< 

< 

CO 

0 

0 0 G G 

Ui  cu 

< 

X u 

< 

< 

<33 

to 

<0  to 

mm 

U 

~J  u 

mm 

»*• 

M 

M 

0 

U 

UCJi»COU- 

G M 

« 

CO  u 0 

> 

> 

> 

to  to 

< 

< 

< 

<0 

s 

G ^ Q 

0 

G 

z 

G 

V 

V V V V V 

V V 

V 

V 

V V 

V V 

V 

V V 

V 

V 

V 

V 

V 

V V 

V 

V 

V 

V 

V 

^occ'ownjrT  ^‘<nwo^^c  o<r  c*u  (\i«o^ir*sOr»><so^o*ii«A<  9 

KK^ocooeeooceodro'o^C'O^O'Oo^cr'ffkoooooooooovN^.M^M* 


FIGURE  5.2  EflNF/WSC  FOR  NOPAL  (continued) 


THIS  PACE  IS  BEST  QUALITY PRJLCtttlAlMI 
FROM  copy  EURKISHED  TO  DD,C  


»-4  <V|  O ^ 

Ok  Ok  OV  0>  Ok 


\0  to  00 
O Ok  ^ Ok 


fsi  lO  ^ 

o o o o o 


■ V 

X 

cs 

V S 

o 

< 

0. 

Z 

a. 

O V 

A 

Uk 

A CS 

* 'v  15 

►— 

W 

S U1 

A £ 2 

£ 

a; 

a Q C/I 

s i/:  s.  f* 

U s 

£ •-  « 

A K < C 

CO 

►- 

U C/l 

O 2 Q.  ►- 

s 

V 

u 

V a u. 

3 W CO 

*• 

£ s 

£ N. 

X 2 V.  V 

s 

>» 

< 

« O 

N. 

Ul  C A 

o 

c; 

N.  ♦ 

CC 

2C  a to  »i 

CO 

U W U X 
V 2 V /\ 

/\  O N.  ►- 
e & u.  2 
O C U.  UJ 
IOC/12 


A,  1 £ Of  Nk 

o o c u»  o* 

3 < O >-  W 

>•  lLJ>- 

u 2 o s:  ui 

^ V w < ^ 

A I - OC  v. 

H>  C s O < 

</l  < W 0.  W A 

^ « U.  I 2 u< 

^ O U.  e c/1 

IV  < UJ  ^ 2 

H-  V X O 

Q.  — a 

^3  no 


5 X 
^ 

ONI/: 

-»  2 N. 
> >“  A 
CO  CO 
V > X 
A to  UJ 
-J  N ►- 
U.  A 1 

m X u 
< >•  o 

-I  2 < 
I O CO 
ul  2 t/l 


s a. 

Z V £ 

a. 

< 

c 

a. 

N» 

r 

u 

A 

a 

z 

ec 

< 

VI 

£ 

V 

z 

A >• 

< 

u 

£■ 

1 

£ 

A 

<0 

(O 

Ul 

Ul 

II 

>- 

f 

CO 

V 

V 

< 

CO  H- 

V 

V 

o 

V 

o 

2 z 

z 

a. 

2 

o 

>• 

N. 

z 

z 

CO 

z 

ca. 

^ CO 

s 

o 

CO 

2 

u 

o 

z 

< 

u 

a 

to 

o 

z 

II 

• 

o 

2 V A 

s 

V 

u. 

£ 

V 

CO 

M 

V a. 

CO 

CO 

X 

u 

V 

z 

£ 

s 

s 

z 

Ui  A (O 

X 

CL 

V 

o 

CO 

25 

o 

V 

to 

% 

^ A 

< 

V 

N 

tl 

Z LJ  H- 

A 

0. 

£ 

• 

A 

2 

z 

< 

s. 

UJ 

u 

u 

z 

X 

oi 

Nw 

X 

O 0.  Z £ 

V 

o u 

s 

CO 

u 

a. 

c^ 

# V r 

A 

X z 

w 

c 

o 

: 

3 

a.  >>  u 

UJ 

a 

> 

z 

N.  V 

£ 

z 

* 

04  V 

V 

>- 

z 

z 

u 

z 

z 

£ ^ Z 

CO 

CO 

u cc 

pm 

V 

s (O 

V 

z 

a 

z 

c5 

z 

O V O LJ 

CO  C- 

V 

A 

£ 

a 

A 

A a 

CM 

< 

A 

V 

V 

o 

CO 

z 

A 

u 

u s a. 

1 

0. 

£ A 

o 

A 

2 

CO  z 

1 

k- 

A 

z z 

22 

z 

22 

% 

(O 

£ 

X 

£ 

to 

1 £ 

£ 

o 

a 

o 

k- 

C5 

< 

< 

Ul 

(O 

< c. 

Ui 

1 z 

z 

II 

£ 

V. 

z 

V 

3 

o •>  o 

z 

o 

o 

u 

z 

cc 

£ 

> 

£ 

M 

CO 

> c 

a 

5. 

h~ 

z 

N. 

N. 

z 

z 

X 

■V. 

W S o u 

Nk 

A 

Ui 

c: 

UJ 

< 

N.  < 

J 

1 N. 

< 

u 

z 

a 

A 

CO 

X 

z 

(J 

z 

*-  • 2 

A 

e 

CO 

1 

£ 

1 

A 

£ 

k- 

V. 

1 J 

Z A 

pm 

o 

£ 

o 

u 

z 

< 

z 

1 

z 

z 

u a o 

e 

o 

f 

C5 

2 O 

I— 

V 

z 

1 o z o 

u 

< 

to 

z 

o 

z 

z 

z 

X 

ce 

u u. 

a 

u. 

• 1 

a 

o 

CO 

CO 

A 

z 

CO 

< 

z 

V u 

V 

V 

z 

£ 

z 

< 

z 

s 

X 

z 

z 

u.  s ►- 

£ 

M 

o 

< 

z 

£ Z 

z 

0. 

> 

< 

» pm 

< 

N* 

X 

CO 

< 

u 

V 

u.  u 

o 

u. 

z 

< 

1 

< 

V 

o 

Ui 

N. 

z 

1 > 

3 U 

22 

z 

II 

CO 

2 

z A 

ru 

< £ W 

o 

< 

U.  A 

o 

1 

u 

N 

£ 

0. 

1 

M 

o 

s 

V 

V 

z 

V 

o 

• 

V OC  u. 

V 

H* 

V 

1 e 

CO 

o 

1 

u. 

c 

o 

o 

a. 

c 

a 

A 

£ 

A 

N. 

55 

\r\ 

r < U. 

z 

s 

0.  Ui 

£ 

CO 

•o 

o 

M 

A Ui 

N*  V 

o 

A z 

< 

z 

z 

z 

V 

z 

A 

a 

z 

0.  < 

Ui 

£ 

V 

£ 

C9 

z 

k- 

-1  £ 

£ 

«w 

V 

Z UJ  z 

k- 

z 

V 

CO 

V 

z ae 

< 

e 

XJj 

— CO  V 

II 

Q 

o u. 

w 

V 

CO  «-«  z 

ui  ^ 

< c 

u 

u 

22 

z 

2 

z 

N. 

A 

z c 

z 

X 

V 

•• 

CJ 

£ 

Ui 

c ^ 

•OT 

mm 

> >- 

2, 

w 

ui 

X 

o 

z 

CO 

II 

s. 

< 

mm 

z 

to 

X 

•• 

V 

V ►- 

N. 

— 

c. 

h-  Q 

< V 

s. 

II 

1 V 

o 

z 

'u 

z 

£ 

•• 

U mJ 

z 

X 

1 

cs 

II 

z a II 

o 

CO 

»i« 

-J  A 

•• 

z 

z 

z 

pm 

z 

CO 

< 

o 

»• 

V 

pm 

z 

22 

— 

•• 

— Ui 

o — 

N 

V 

V 

1 z 

•• 

o /o 

< o 

z 

w 

z 

< 

z 

V 

< 

z 

•• 

A 

n 

o 

ec 

U Ui 

II 

V CO 

2 

5 

z 

22 

< 

(O 

CO 

s 

r 

CO 

«• 

o 

• 

c5  m 

•• 

z 

z 

V 

Z A 

CO 

II 

z 

u 

►- 

•• 

V c 

If 

11 

< £ 

•• 

A 

z 

II 

V 

22 

u 

*• 

25 

M 

V 

A 

z 

Z A 

•• 

•• 

CO  2 

Ui 

II  z 

•« 

pm 

— 

V 

o 

£ 

•• 

z 

•• 

LJ 

UJ 

<•  10 

•• 

•• 

CO  Z 

<0 

••  o 

•• 

II 

z . 

>u 

V 

•« 

C9 

z 

A 

II 

>*  a: 

Ui  V 

A 

z 

••  'v 

«• 

It 

z 

II 

< 

o 

£ 

«• 

Ui 

£ 

z 

o 

•• 

•• 

II 

M 

A 

*• 

CO 

0. 

w 

•• 

H- 

A 

A 

V 

o 

0. 

A 

• • 

•• 

£ 

II 

z 

II 

A 

• • 

CO 

r 

Cl  Ui 

A 

If 

<o 

A If 

o 

•• 

z 

•• 

z 

•• 

pm 

Ui 

Q 

Ui 

— £ 

o 

2 

* •« 

to 

UJ 

^ •• 

« 

A 

z 

•• 

m 

•• 

X 

£ 

CJ 

1 

A 

•*  < 

UI 

Ui 

II  •• 

z 

z 

c/1  •• 

M 

o 

A 

z 

< 

z 

A 

1 

1 

u- 

Z £ 

•• 

ui 

1 

«« 

2 

3 

22 

A 

2 

z 

z 

r 

a: 

c 

2 

z 

< 

I 

2 

•• 

£ 

z 

1 

V 

z 

u 

1 

A 

1 

A 

1 

z 

o 

w 

u 

u 

A a 

C5 

o 

A 

M 

o 

1 A 

Q 

z 

z 

u 

z 

Z £ 

z 

z 

z 

Z 1 

z 

z 

c 

z z 

z 

X 

z 

2 

(5 

C5 

<5 

z 

c 

z 

< 

u 

o 

o 

o c 

< 

< 

A z 

1 < 

< < 

Q 

1 

a 

< 

< 

< 

2 

1 

flC 

UI 

& 

1 u; 

1 

1 

UJ  ^ 

u 

z 

> 5 

3 

o 

< 

z 

CO 

CO 

CO 

o 

(O 

z 

Ui 

h. 

£ 

£ 

o z 

o 

o 

Z £ 

£ 

Ui 

1 t X 

< 

CO 

CO 

CO  CO 

to  X 

0. 

u. 

o 

c 

2 »- 

CO 

CO 

X «-i 

a. 

z z 

u 

< 

z 

z 

w 

u 

z 

z 

o 

< 

u 

u 

< o 

£ 

£ 

o 

o o 

JC 

Q 

2, 

22 

c 

£ 

£ 

C.0 

£ 

z 

V 

V 

V 

V 

V V 

V 

V 

V V 

V 

V 

V V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

kn»ah-o<r*o«^<^f^arir»vOf*<c(ro»-*(v*o^4nxor^«<T'o*^<M‘o^trt\^h-o<r*o«"<v^ 


j 


FIGURE  5.2  EBNF/WSC  FOR  NOPAL  (continued) 


IHIS  PAGE  IS  BEST  QUAI/lTT 
FSHM  CXtirX  EJ^hWISiffiD  lOBIiQ 


ro  ^ vn 

(Ni  Csl  CV| 


NO  00 
rvj  CM 


j ^ 1 


X 

o 

X 

V 

X 

z 

X 

E 

c: 

q: 

UI 

X 

E 

< 

< 

4 

X 

< 

E 

a. 

0. 

z 

0. 

< 

E 

E 

e 

A 

Q£ 

>- 

> 

E 

X 

N. 

K 

X 

<0 

H- 

to 

X 

X 

(0 

z 

« 

z 

s 

X 

z 

u 

s 

X u 

u. 

X 

z 

: 

V 

.J 

cu  z 

X 

A 

X 

►- 

1 

s 

OC  3 

A 

c 

E 

a. 

X 

» 

u u. 

u 

Ul 

z 

U 

z 

< 

: 

.J  ►- 

a 

X 

2 

A 

to 

u 

r 

X 

s 

: 

ffl  (0 

CO 

E 

CO 

z 

> 

V 

-1 

X 

A 

►->  X 

K 

z 

3 

E 

t/i 

: 

1- 

X ♦ 

1 

A 

mm 

X 

X 

(O 

a 

z 

a. 

U 

CO 

c 

A 

A 

» 

z 

ce 

z 

o 

s 

E 

z 

O 

3 

I- 

s 

0. 

CO 

o 

S A 

z 

1 

o 

u 

c 

Z 

X 

c 

0. 

••  c 

►- 

Li. 

CO 

w 

1 

1 

M 

A 

0. 

I 

s 3 

u 

X 

UJ 

I— 

Ui 

z 

c 

K 

X 

> 

z 

A 

3 

o 

> 

o 

c 

Q. 

s 

A 

o 

Ui 

3 

a 

z 

0 

1 

X z 

►- 

X 

Lj. 

u 

< 

3 

►- 

u 

Z 

z 

M 

z 

I— 

s I 2 

V 

> 

u. 

u 

u 

z 

C -I 

u 

X z 

>• 

Ui 

V 

1 

Ui 

z 

o 

V 

L/1 

1 

o 

X 

Ui 

o 

CO 

11 

1- 

E 

►- 

X 

3 X 

u 

0. 

z 

z 

0. 

z 

» z 

a *-4 

> 

2 

A 

If 

O 

z 

o 

u 

E 

E 

< 

Q.  V 

>- 

0. 

1 

Q 

z 

Ul  ^ 

CO 

UI 

z 

O 

X 

E 

CJ 

V 

U 

E 

>-  V 

X 

z 

u 

CO 

2 O 

CO  <J 

X 

CL 

1 

a 

E 

r\ 

CO 

X 

to 

o 

>-  C\J 

z 

A 

V 

u 

z 

A o 

> z 

A 

>- 

3 

< 

r 

V 

>• 

V 

z 

CM 

z 

z 

z s 

u 

2 

2 

(L 

Z 1 

CO  3 

z 

►- 

u; 

C- 

C 

u 

h~ 

u 

E 

E 

u u 

> 

O 

Ui 

X 

o u 

X u. 

>• 

z 

V 

u 

11 

co 

: 

X u 

X 

E 

> ^ 

</) 

• 

2i 

A 

M H- 

A V 

z 

ca 

z 

— 

z 

II 

A 

O 

(/3  CD 

X 

CO 

s 

Ui 

Z 

H>  < 

« • 

o 

r 

a 

E 

A 

E 

X 

c 

S 

A 

E 

V h* 

z 

Lu 

o 

U V 

a z 

2 

A 

CO 

3 

-» 

u 

X 

Of 

M 

h- 

a 

A V 

A 

UJ 

2 S 

u 

>• 

Z 

z 

A 

h- 

O 

A 

u 

1 

X 

CJ 

U • 

u 

z 

X 

CO 

3 

CO  X 

CO 

o 

3 

ac 

U 

A 

— 

U 

>- 

2 

1 

CO 

0.  s 

0. 

z 

V 

z 

LL 

1 u 

V 

V 

Ul 

c; 

CO 

E 

LJ 

o 

s 

z 

3 

>• 

o 

X 

X 

UI 

1 A 

>-  z 

1— 

u- 

r 

< 

♦— 

u 

iC 

*-4 

o 

X 

H- 

V -1 

CO 

z 

A 

U H- 

X 3 

II 

u 

II 

Ui 

E 

z 

H* 

X 

mm 

E 

1 

1 

X 

q: 

o 

►-  2 

U» 

z 

sz 

U 

Ul 

•“ 

1 

H* 

A 

u 

z 

Z 

z 

* 1 

CO 

UJ 

o 

< 

Z Ui 

CO 

3 

CO 

< 

Ul 

E 

z 

z 

mm 

O 

2 

u 

m 

z 

z 

w 

z 

V 

1 

V o 

Ui  *- 

< 

u. 

z 

E 

3 

O 

z 

z 

E 

z 

z 

3 

Z 

E 

o 

o 

X 

CL 

to 

w 

: 0. 

V < 

V 

M 

< 

o 

o 

<C 

M 

E 

3 

u 

o 

X 

H 

•- 

z 

4 t 

r X 

: 

G. 

a 

< 

u 

u 

— 

a 

E 

V 

E 

CO 

V 

V 

z 

X 

z 

A 

< 

s 

V 

> 

V 

V 

V 

: 

u- 

X 

V 

• 

\ 

A «/ 

• 

o 

A O 

A Q 

X 

CO 

: 

co 

ro 

X 

<M 

C 


ffi 


— A a:  »- 
c;  ui  uj 
u >-<  o 

N. 


♦-  2 II 
Z W *• 
Ui  o •« 
o M 
« V 
V A 
C/) 


c.  z « 

I C K 
^ tJ 
3 >-  UJ 
3 U Z 
V z z 
3 o 

Li.  U 
II  I I 
••  LJ  UJ 

^ H* 
< < 
V V 


C I d 
^ Z Ui 

H-  o 
u m 

Z h-  I- 
3 u V 

u.  z 

V D 

Li.  n 

V •• 

II 


QC 

u 

2 A 
u.  u 
V s: 
< 
z 

11  I 

••  c 

••  cr 


< ^ 
e c 
u I- 
Q-  ^ 
O 

c 

u 

\ II 


ca 

(X 

u 


11  K 

A 

• * 

< 

z 

A 

E 

11 

••  E 

If 

ft 

E 

A 

a. 

< 

a o 

• • 

A 

A 

••  z 

•• 

•• 

z 

II 

o 

A V 

0. 

••  E 

CO 

S 

•• 

E 

•• 

•• 

E 

•• 

A 

z 

E — 

V 

••  Z 

z 

o 

n 

•« 

2 

E 

a 

z 

A 

o 

E 

A 1 

E 

o ‘ 

E 

E 

•• 

' o 

2 

E 

o 

A 

E LJ 

A 

A 

1 

E 

X 

E II 

A E 

o 

E 

E 

U 

2 > 

E 

E 

Ul 

A 

E 

1 

1 •• 

E E 

E 

E 

Z 

E 

E E 

E 

E 

CJ 

CJ 

Ul 

Z 

3 •• 

E & 

E 

r 

z 

E 

O E 

z 

z 

2 

u 

z 

o 

O 

E 1 

< 

3 

o 

E 

E CJ 

E 

E 

E 

E 

3 

E 

E 

►-  to 

Z 

U 

u 

1 

1 U 

.J 

sz 

CO 

u. 

E 

H*  A 

1 U 

E 

1 

1 

Z 

Z E 

1 

1 u 

1 

1 

U> 

CJ  Z 

Z 3 

a 

u 

E 

z 

z o 

K 

z 

u. 

u 

E 

z 

z z 

Z E 

c 

o 

3 

o 

o E 

< 

E 

Ul 

E 

E 

3 

3 < 

< < 

c 

o 

3 

u 

CJ  E 

Z 

z 

e 

<C 

< 

E 

E E 

E > 

CJ 

u 

V 

V 

V V 

V 

V 

V 

V 

V 

V 

V V 

V V 

V 

'✓ 

UJ 


C5 


oc'J'C^cr'7'i7'^<r‘T'<7'oooooooooo»^i-*«^*H«-*^*H.-^«M*i^oj 

<V<VA<V<\i  <VA'A'<V/<\‘  Ai<\  AC\j  <VA/Oj 


C'  O 
<M  A* 
A- 


119 


CO 


CO  o>  o 
eo  ro  ^ 


V 

V o 

, ^ 2 

e uj 

or 

»» 

< 

^ s 

0. 

£ ►- 

ce 

f/i 

>* 

V V 

V 

« 

S GL 

s 

•• 

X 

s ^ 

a 

< 

K 

o. 

S N. 

> 

Nfc  • 

•Ji 

« 

•s 

O S 

A 

U A 

C 

(/)  O 

A 

> 3 

(/: 

1 

(/)  > 

N ►- 

►- 

X U 

z z 

z 

A X 

> IX 

« 1 

</)  o 

o 

O ^ 

> a. 

0. 

U 2 

(/)  1 

1 

(0  M 

's  ^ 

N. 

1 o 

A 3 

3 O 

^ a. 

£ 3 

3 « 

e • 

> V 

V ^ 

^ u 

z 

- a. 

2 ►- 

O M 

s > 

U < 

z 

(/} 

V V 

V A 

'S 

s • 

«/)  ^ 

A V A 

s 

V Z (/)  o o 

A 

M 

^ M M 

►-  V 

11  O Z ^ 1 

Z -i 

M (D 
O -J 
CL  > 
I c/) 
Ui 


a u a.  H- 

cn  I £ > 2 
< ^ £ (/)  M 

3 O V O 
j 3 u A a. 
A < V V C I 


^ A 

s 

V 

< O 

u 

^ •• 

“ 1 3 

V 

^ 3 

1 

u. 

u 

Z V 

V 

II  Z 

V ^ a 

O CM 

H-  3 

C.  CL 

••  O 

Z UJ 

\ u 

0.  0.  o 

I-  J 

1 

1 M 

3 CC 

A Ui 

U V 

II 

3 ►- 

►-  ^ 

►- 

•• 

V V 

Z < 

< 

•• 

V 

V II 

• 

o 

•• 

0. 

•• 

A 

II 

1 

II 

O 

•• 

z 

•• 

3 

• • 

o 

••  A 

> 

M 

n 

UJ 

u> 

M 

X 

A 

u> 

A « 

1 

VI 

u 

z 

z z 

'z 

z 

z 

M 

o 

c o 

c 

o 

u 

1 

a.  a. 
1 1 

a 

c. 

1 

1 

u 

Ul  u 

u 

H*  ^ 

3 

< 

< < 

< 

3 

V 

V V 

V 

V 

OiK>^tnvor*«T»o 


120 


FIGURE  5.2  EBNF/WSC  FOR  NOPAL  (continued) 


in  Figure  3.1  the  EBNF/WSC  specification  includes  the  following  two 
modifications: 

(1)  the  EBNF  specification  has  been  restructured  to  conform  to 
restrictions  explained  in  Section  5.2.3,  imposed  by  the  SAPG 
processor. 

(2)  the  names  of  the  invoked  subroutines  are  embedded  in  EBNF 
(enclosed  in  slashes). 

The  left-hand  column  in  Figure  5.2,  marked  "EBNF/WSC  Line  Number", 
shows  the  line  (or  card)  number  of  EBNF/WSC  for  NOPAL.  The  right- 
hand  column,  marked  "EBNF  Reference  Number',  indicates  the  statement 
(production)  number  of  the  corresponding  EBNF  statement  of  Figure  3.1. 
Where  one  EBNF  statement  corresponds  to  more  than  one  EBNF/WSC  state- 
ment, the  same  EBNF  reference  number  appears  in  all  of  the  EBNF/WSC 
statements . 

To  illustrate  the  relationship  between  EBFF  and  EBNF/WSC  state- 
ments, the  following  is  an  example  from  the  EBNF  specification  of 
Figure  3.1  (Statement  85). 

<DIAGNOSIS_DEFrNrTION>  ::=  DIAGNOSIS  <DIAG_LABEL > [:] 

<DIAG_B0DY>  ; 

In  the  EBNF/WSC  specification  on  lines  109-110  of  the  Figure  5.2,  the 
above  becomes  the  following: 

<DIAGNOSIS_DEFINITION>  ::=  <DIAGNOSIS>  /DIAGI/  <DIAG_LABEL> 

/SVLBL/  [:]  <DIAG_B0DY> 
/STDIAG/  /STMTEND/ 

This  means  that  the  non-terminal  < DIAGNOSIS_DEFINITION  > starts 
with  the  syntactic  unit  <DIAGNOSrS>  . The  corresponding  recognizer 
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routine  will  recognize  the  keyword  DIAGNOSIS.  If  this  keyword  is  suc- 
cessfully recognized,  the  subroutine  DIAGl  is  called.  This  routine 
will  allocate  and  stack  an  error  message  code  for  a missing  succeeding 
syntactic  unit  (which  in  this  case  is  <DIAG_LABEL>  ).  Then  another 
procedure  is  called  to  recognize  the  next  syntactic  unit<DIAG_LABEL>  . 
If  <DIAG_LABEL>  is  successfully  recognized,  the  routine  SVLBL  is  in- 
voked, which  will  encode  and  save  the  recognized  token.  Otherwise,  the 
error  message  will  be  sent  to  the  user.  Then  a colon  (:)  may  optional- 
ly follow.  Next  comes  the  last  non-terminal  < DIAG_B0DY > (it  will 
define  the  ATE  operator  message  and  operator  response  in  another  pro- 
duction). If  the  foregoing  is  successful,  the  subroutine  STDIAG  is 
called  to  store  the  statement  in  the  simulated  memory,  by  calling, 
in  turn,  the  STORE  subsystem  (to  be  explained  later).  Finally,  the 
subroutine  STMTEND  is  invoked.  It  will  check  the  statement  end  marker 
(; ) and  increment  the  statement  number. 

Further  examples 'of  inserting  subroutine  calls  into  the  EBNF/WSC 
will  be  given  later  when  each  category  of  subroutines  (.such  as  recogni- 
zer and  saving/encoding)  is  discussed  in  the  following  sections. 

In  summary,  SAP  is  generated  by  SAPG  based  on  the  EBNF/WSC  speci- 
ticaticri  of  NOPAL  and  linked  with  the  s-ubroutines.  Then  SAP  accepts 
NOPAL  statements  and  checks  them  for  syntactic  correctness  and  some 
local  semantics,  encodes,  and  stores  the  statements  in  the  simulated 
associative  memory  for  further  processing. 

5.2.2  HOW  SAPG  PRODUCES  SAP 

As  indicated  in  Figure  5.1,  SAPG  produces  SAP  based  on  the  EBNF/ 
-*icc-:  the  NC'^AL  language.  The  design  of  SAPG  is 
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documented  in  [RAM  73]  and  its  implementation  in  [ FRE  72  J . The 
operation  of  SAPG  fs  briefly  sumnarized  in  the  following  paragraphs, 
but  the  above  documentations  should  be  referred  to  for  more  details. 

SAPG  itself  is  a small  compiler  which  accepts  as  input  a formal 
description  of  a given  language  L (here  NOPAL)  expressed  in  a meta- 
language EBNF/WSC.  It  produces  a PL/1  program  (SAP)  which  analyzes 
the  statements  in  the  language  L and  coordinates  the  encoding  and 
storing  of  the  statements  in  an  internal  form.  SAPG  processes  the  set 
of  EBNF/WSC  source  statements  (i.e.,  productions)  in  the  following 
three  passes. 

In  Pass  1,  it  performs  lexical  analysis  of  the  EBNF/WSC  productions 
and  encodes  them  in  an  "Encoded  Table."  Non-Terminals  appearing  on  the 

left-hand  side  of  the  symbol  ::=  in  a production  are  placed  in  a 
"Symbol  Table,"  while  non-terminals  appearing  on  the  right-hand  side 
are  putinto  a "Work  Table."  Subroutine  calls  and  terminal  symbols  are 
placed  in  subroutine  and  terminal  symbol  tables  respectively.  Alto- 
gether SAPG  maintains  five  i'rTternal  tables  (Encoded,  Symbol,  Work, 
Terminal,  and  Subroutine). 

In  Pass  2,  SAPG  scans  the  Encode  Table  to  resolve  the  symbolic 
references  in  the  Work  Table  (i.e.,  finds  non-terminals  on  the  right- 
hand  side  of  the  original  production).  It  checks  that  each  non- 
terminal on  the  right-hand  side  of  a production  is  defined,  and  links 
it  to  the  corresponding  entry  in  the  non-terminal  symbol  table.  Un- 
defined, as  well  as  circularly  defined,  nonterminals  are  detected  in 
this  phase  and  reported  as  errors. 


In  Pass  3,  SAPG  generates  SAP  code  in  PL/I.  This 
phase  of  SAPG  is  entered  only  if  no  errors  were  detected 
in  the  first  two  passes.  For  each  EBNF/WSC  production,  a 
PL/I  Procedure  is  generated,  which  returns  a 1-bit  value. 
The  procedure  returns  a 0 value  on  failure  of  recognition 
of  the  first  syntactic  unit  on  the  right-hand  side  of  the 
symbol  in  the  production.  Otherwise,  it  returns  a 

1 value.  The  exclusive  nature  of  EBNF  production  rules 
and  alternatives  is  implemented  by  PL/I  IF-THEN-ELSE 
statements.  Repetition  brackets  ([...]*)  in  a production 
cause  generation  of  GOTO  statement  in  a place  of  SAP  to 
scan  again  the  first  syntactic  unit  of  the  group.  Each 
subroutine  name  embedded  in  slashes  in  EBNF/WSC  becomes 
a ’’call"  statement  for  the  subroutine.  Calls  to  the 
lexical  scanner  LEX  and  other  "housekeeping"  subroutines 
are  also  inserted  in  SAP,  as  indicated. 

As  an  example  of  the  SAP  code  that  SAPG  produces, 
consider  the  following  representative  production  rules 
(EBNF/WSC  lines  109-112  and  59  of  Figure  5.2); 

< DIAGN0SIS_DEFINITI0N  > < DIAGNOSIS  > /DIAGl/ 

< DIAG_LABEL> /SVLBL/  [:] 

< DIAG  BODY  >/STDIAG/ 


/STMTEND/ 


•iDIAGNOSIS  > ::=  /DIAGNOS/ 

<DIAG_LABEL  > ::=  <LABEL> 

<LABEL  > : : = /LABEL/ 

The  corresponding  PL/I  code  generated  for  it  by  SAPG 
in  the  third  pass  is: 

D1AGN0SIS_DEFINITI0N : PROCEDURE  RETURNS  (BIT(l)); 
CALL  SHARK; 

IF  DIAGNOS  THEN 
DO;  CALL  $POPF; 

CALL  DIAGl; 

IF  LABEL  THEN 

DO;  CALL  $POPF; 

CALL  SVLBL; 

$SYS_049:  CALL  LEX; 

IF  LEXBUFF  = ' : ' THEN 

DO;  CALL  LEXENAB;  END; 

ELSE  ; 

IF  D1AG_B0DY  THEN 

DO;  IF  ERRORSW  THEN 

DO;  CALL  SSUCCES; 

RETURN/  ' 1 ' B)  ; 

END  ; 

ELSE.; 

CALL  STDIAG; 

CALL  STMTEND; 
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CALL  $SUCCES; 


RETURN( ' 1 ' B)  ; 

END  ; 

END  ; 

ELSE  DO;  CALL  $FAIL;  RETURN (' 1 ' B ) ; END; 

END  ; 

ELSE  DO;  CALL  $FAIL;  RETURN (' 0 ' B ) ; END: 

END  DIAGNOSIS_DEFINITION; 

The  above  code  would  become  an  internal  procedure 
in  SAP.  The  subroutines  beginning  with  a dollar  sign  ($) 
are  "housekeeping"  routines,  which  are  internal  to  the 
mechanisms  of  SAPG.  Normally,  they  do  not  concern  the 
language  definer.  These  routines  are  further  discussed 
in  Section  5.3.6.  Two  "recognizer"  routines  (DIAGNOS 
and  LABEL)  are  illustrated  in  the  above  example.  If 
a subroutine  appears  alone  as  the  right  part  (i.e.,  the 
part  to  the  right  of  the  symbol  ;:•)  of  a production,  the 
subroutine  is  determined  by  SAPG  as  a recognizer  routine. 
For  example,  DIAGNOS  is  a recognizer  routine  because  of 
the  production  "<DIAGNOSIS  > : ; « /DIAGNOS/  ".  Recognizer 

routines  and  their  references  are  further  explained  in 
Section  5.3.3.  How  SAPG  generates  the  above  PL/l  code  is 
briefly  explained  in  the  next  paragraph. 

Before  generating  the  code  for  the  production 
< DIAGNOSIS_DEFINITION  , SAPG  has  determined  that 
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DIAGNOS  and  LABEL  are  recognizer  routines  and  hence  that 
•'DIAGNOSIS  > and  ■'DIAG_LABEL  > in  this  production  are  the 
non- terminals  associated  with  the  two  recognizer  routines. 
First,  SAPG  generates  D I AGNOS I S_DEF INITION  procedure 
header  based  on  the  production  named  <DIAGNOSIS_DEF- 
INITION  > . Then  "CALL  $MARK;"  is  generated  to  mark  in 
the  error  stack  the  beginning  of  error  codes  for  this 
production.  Next  comes  the  non-terminal  <DIAGNOSIS  > 
which  has  been  determined  to  be  associated  with  the 
recognizer  routine  DIAGNOS,  hence  "IF  DIAGNOS  THEN  DO; 

CALL  $POPF;"  is  produced.  "CALL  $POPF:"  is  generated 
to  pop  the  top  error  code  from  the  error  stack,  if  any. 
Then,  /DIAGl/  subroutine  call  is  encountered;  therefore, 
the  corresponding  "CALL  DIAGl;"  PL/I  statement  is 
generated.  Then  comes  <DIAG_LABEL>  , associated  with 
the  recognizer  routine  LABEL,  as  indicated,  hence  "IF 
LABEL  THEN  DO;  CALL  $POPF;"  is  produced.  "CALLSVLBL:" 
is  then  generated  due  to  the  immediately  following  sub- 
routine call  /SVLBL/.  Now  a left  bracket  ([),  signal- 
ling the  beginning  of  an  optionality  group,  is  encounter- 
ed, hence  a unique  PL/I  statement  label  (in  this  case. 
"SYS_049:")  is  generated.  Then  comes  the  terminal  symbol 
colon  (:).  A call  to  the  lexical  analyzer  (LEX)  is 
generated.  If  the  current  token  (in  LEXBUFF)  is  a colon. 


a call  (LEXENAB)  to  "enable"  the  LEX  is  also  generated. 
Then  < DIAG_BODY  > follows,  which  is  defined  in  another 
production.  Thus,  "IF  DIAG_BODY  THEN  DO;  IF  ERRORSW  THEN 
DO;  CALL  $SUCCES;  RETURN('l’B);  END;  ELSE;"  is  produced. 
This  causes  SAP  to  restore  the  error  stack  (by  calling 
$SUCCES)  and  return  value  1 (true)  if  some  errors  have 
been  detected  (and  hence  error  switch  "ERRORSW"  has  been 
set)  in  the  procedure  for  the  production<  DIAG_BODY  > . 
Finally,  two  subroutine  calls  /STDIAG/  and  /STMTEND/ 
follow,  hence  "CALL  STDIAG;"  and  "CALL  STMTEND;"  are 
generated  respectively.  The  PL/I  DO  group  is  wrapped  up 
after  restoring  the  error  stack  (CALL  $SUCCES)  and  ret- 
urning true.  All  ELSE  groups  except  the  very  last  one 
are  completed  by  "CALL  $FAIL;  RETURN (' 1 ' B );" , which 
issues  an  error  message,  restores  the  error-stack,  and 
returns  a true  value.  The  last  else  group  is  closed  in 
the  same  way  except  it  returns  a false  value.  At  the  end 
of  the  production  <DIAGNOSIS_DEFINITION  > , the  "END 
DIAGNOSIS_DEFINITION ; " is  generated  to  end  the  procedure 
def inition . 

5.2.3.  LIMITATIONS  AND  IMPLEMENTATION  RESTRICTIONS  OF  SAPG 
SAPG  together  with  EBNF/WSC  has  proved  to  be  a very 
useful  tool  for  defining  the  NOPAL  language,  because  it 
allows  changes  to  the  language  to  be  made  relatively 
easily  during  its  development.  The  alternative  of  writing 


the  syntax  and  statement  analysis  program  manually  would 
be  muc,h  more  tedious.  Although  the  SAPG  approach  has  been 
found  adequate  far  generating  SAP  for  NOPAL,  some  limita- 
tions are  mentioned  below. 

The  first  limitation  is  that  SAPG  only  generates  a 
SAP  which  performs  statement-by-statement  analysis  to 
verify  syntactic  and  local  semantic  correctness,  the 
former  directly  and  the  later  through  subroutine  calls. 
Consequently,  global,  in t e r - s t a t emen t analysis  is  handled 
beyond  the  scope  of  SAP.  Fortunately,  NOPAL  language  is 
non-procedural,  and  each  statement  is  independent.  It 
turns  out  that  the  stateraent-by-statement  local  analysis 
is  appropriate  and  adequate  as  a first  pass.  Global 
analysis  of  the  NOPAL  specification  is  one  of  the  major 
tasks  of  the  NOPAL  processor  to  be  discussed  i^n  Chapter  6. 

SAPG  has  however  several  disadvantages.  It  is 
necessary  for  a language  definer  to  define  in  PL/I  all 
error-message  routines  and  to  insert  the  names  of  these 
routines  in  the  EBNF/WSC  specification.  This  is  a tedious 
and  time-consuming  task,  which  requires  a modification  of 
the  SAPG  system.  The  SAPG  system,  in  principle,  could  be 
designed  and  implemented  in  such  a way  that  it  would  auto- 
matically generate  the  error  messages  for  missing  or 
incorrect  syntactic  units,  based  on  the  EBNF/WSC  speci- 
fication. 
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A standard  facility  (store/retrieve  subsystem) 
for  storing  source  language  statements  was  developed 
and  added  to  the  original  SAPG  by  the  University  of 
Pennsylvania  MODEL  project  [RIN  76].  However,  the 
store/retrieve  procedures  have  been  completely  re- 
written to  fulfill  some  special  requirements  of  NOPAL, 
and  to  Increase  the  efficiency  of  storing  and  retrieving 
Note  that  routines  for  encoding  of  syntactic  units 
temporarily  saving  of  data  and  Invoking  the  STORE  sub- 
system (to  store  statements)  must  still  be  written 
manually. 

There  are  some  restrictions  on  the  way  EBNF/WSC 
is  used  to  specify  a language,  due  to  the  way  SAPG 
has  been  implemented.  SAPG  does  not  generate  a run 
time  stack  for  syntactic  units  during  syntax  analysis 
and  hence  does  not  have  a backtracking  capability,  Thus 
the  generated  parser  SAP  is  strictly  sequential.  As  a 
consequence,  the  first  restriction  Is'that  no  pro- 
duction rule  in  the  EBNF  (and  hence  EBNF/WSC)  specifi- 
cation can  Involve  left  recursion , A production  is  left 
recursive  if  the  first  symbol  on  the  right-hand  side  of 
the  symbol  is  a non-terminal  which  is  the  left-hand 

side  non -terminal  Itself,  or  which  eventually  references 


the  left-hand  side  noa-terminal  through  valid  sub- 
stitution. A solution  to  this  problem  presented  by 
the  original  SAPG  system  is  o circumvent  the  left- 
recursion  restriction  by  using  the  repetition  feature 
of  EBNF.  In  fact,  left-recursion  can  easily  be 
•eliminated  from  a context  free  grammar  [AHO  72].  A 
discussion  of  a method  by  which  most  recursion  can  be 
transformed  into  iteration  may  be  found  in  [CAR  69]. 

A second  restriction  is  that  an  optionality  group 
must  be  distinguished  by  its  first  syntactic  unit 
(terminal  or  non-terminal).  In  other  words,  the  first 
syntactic  unit  which  immediately  follows  the  optionality 
group  must  be  different  from  the  first  syntactic  unit 
of  the  optionality  group.  For  example,  if  "[,KEYW0RD1 
» ...]  ,KEYW0RD2  - ..."  appeared  in  a production  and  the 
comma  (",")  itself  were  a lexical  unit  (in  NOPAL 
processor  the  comma  is  truly  a lexical  unit),  it  would 
be  impossible  to  determine  by  scanning  a comma  to  which 
group  the  comma  should  belong.  This  would  be  overcome 
if  the  lexical  routine  were  made  to  have  back-tracking 
capability.  Another  solution  is  to  treat  the  comma 
(",")  as  part  of  the  keyword.  The  last  alternative  is 
to  rewrite  the  EBNF  specification  to  remove  such 
occurrences,  if  possible. 

The  final  restriction,  also  stemmingfrom  the  strict 
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sequentiality  of  SAP,  is  that  every  alternative 
of  a given  production  rule  must  be  distinguishable 
by  its  first  element.  To  illustrate  this,  consider 
the  following  example  of-  four  productions  (statements 
91,  92,  112,  and  26  of  EBNF  for  NOPAL  in  Figure  3.1): 

< COMPONENT_CONJUNCT  COMPONENT  > 

I <FAILURE_FUNCTION  >(<  COMPONENT  > 

[ & < COMPONENT  > ] *) 

< COMPONENT  IDENTIFIER  > 

< FAILURE_FUNCTI0N  FUNCTION_ID  > 

< FUNCTION_ID  IDENTIFIER  > 

In  the  above  example,  both<  COMPONENT  > and  < FAILURE_ 
FUNCTION  > are  defined  as  < IDENTIFIER  >.  In  order  to 
recognize  a string,  say,  "OPEN  (RESISTOR)"  as  a 

< FAILURE_FUNCTION  > (<  COMPONENT  > ) and,  in  turn,  as 
a < COMPONENTJ^CONJUNCT  > a syntax  parser  with  back- 
tracking capability  could  first  try  the  < COMPONENT  > 
alone  as  first  alternative,  where  "OPEN"  would  match 
but  the  remaining  string  "(RESISTOR)"  would  not.  Then 
the  parser  would  have  to  backtrack  and  try  the  second 
alternative,  where  "OPEN  (RESISTOR)"  would  be  found 

to  match  < FAILURE_FUNCTION  > (<  COMPONENT  >)  perfectly 

Due  to  lack  of  such  a backtracking  capability,  SAPG 
requires  that  each  altern.ative  to  be  taken  must  always 
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be  determinable  by  the  current  token.  To  conform  to 
this  SAPG  restriction,  the  above  example  could  be 
rewritten  by  "factoring  out"  the  common  prefix 

< IDENTIFIER  >as  follows: 

< COMPONENT_CONJUNCT  >;:«  < IDENTIFIER  > < FUNC_OR_COMP  > 

< FUNC_OR_COMP  > [(<  COMPONENT  >[&<  COMPONENT  >]*)] 

< COMPONENT  > ::=  < IDENTIFIER  > 

This  restriction  was  the  reason  for  restructuring  some 
productions  in  the  EBNF/WSC  of  NOPAL  from  the  EBNF . 

The  above-mentioned  two  restrictions  make  the 
writing  of  the  grammar  somewhat  awkward.  EBNF/WSC  for 
NOPAL  has  been  written  in  this  form  by  factoring  out 

common  syntactic  units  to  higher  levels  in  the  parse  tree 

o, 

and  using  keywords  to  uniquely  identify  paths  or 
optionality  groups.  SAPG  with  these  restrictions,  however, 
is  still  adequate  for  the  class  of  languages  such  as 
NOPAL. 

In  conclusion,  while  the  SAPG  system  has  some  minor 
limitations  and  restrictions,  it  has  been  an  adequate 
tool  for  defining  NOPAL. 

5.3  SUPPORTING  SUBROUTINES  FOR  EBNF/WSC  OF  NOPAL 

A flowchart  showing  SAPG  and  SAP  with  the  types  of 
supporting  subroutines  is  shown  in  Figure  5.3.  The 


EBNF/WSC 


FIGURE  5.3  MORE  DETAILED  SYSTEM  FLOWCHART  OF 
SAPG  AND  SAP  WITH  SUBROUTINES 


manually-written  supporting  routines  are  of  the  follow- 
ing six  types: 

1)  lexical  analyzer:  scans  the  NOPAL  input 

string  and  Returns  tokens  of  syntactic  units 
to  SAP  or  the  recognizer  routine  for  analysis; 

2)  • error  message  stacking:  composes  and  stacks 

error  message  codes; 

3)  recognizer : recognizes  a class  of  input  tokens, 
such  as  names  and  integers  and  returns  true/ 
false  results  to  the  SAP  or  another  recognizer 
depending  upon  whether  the  recognition  is 
successful  or  not; 

4)  encodlng/savlng/storing:  compacts,  temporarily 
saves,  and  stores  NOPAL  statements. 

5)  semantics  checking:  checks  some  local  semantics 
of  statements;  and 

6) '  housekeeping : required  by  the  SAPG  system  in 

order  to  perform  some  services. 

The  above  six  types  of  routines  are  described  in 
detail  in  the  following  subsections.  At  the  end  of  each 
NOPAL  statement  a storing  routine,  which  calls  in  turn  the 
STORE  subsystem  of  a STORE/RETRIEVE  package,  is  invoked 
to  store  information  of  the  statement.  The  STORE/ 
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RETRIEVE  package  is  discussed  in  the  next  Section  5.4. 

The  two  specification  reports,  source  and  r e f orraa  t,t  ed  , 
together  with  the  syntax  error  report  are  presented  in 
Section  5.5;  the  six  cross  reference  reports  as  Indicated 
in  Table  5.1  are  discussed  in  Section  5.6. 

5.3.1  LEXICAL  ANALYZER  FOR  NOPAL 

The  purpose  of  the  lexical  analyzer  (scanner)  is  to 
scan  the  source  input  consisting  of  NOPAL  statements  for 
syntactic  units  or  "tokens",  and  to  return  them  to  the 
Syntax  Analysis  Program  (SAP)  or  the  calling  recognizer 
routine.  The  lexical  analyzer  (LEX  or  SCAN)  is  invoked 
whenever  the  next  token  is  needed  for  syntactic  checking. 

The  lexical  analyzer  routine  is  based  upon  the 
concept  of  finite  state  machines  [CON  63].  Each  state 
of  the  machine  corresponds  to  a condition  in  the  lexical 
processing  of  a character  string.  At  each  state,  a 
character  is  read,  an  action  is  taken,  and  the  machine 
changes  to  a new  state.  The  charac t er  classes  for  the 
NOPAL  language  for  the  purposes  of  lexical  analysis  are 
shown  in  Table  5.2.  The  whole  character  set  is  divided 
into  eleven  categories  such  as  alphabets,  digits, 
delimiters,  and  special  operators.  The  state  transition 
diagram  appears  in  Figure  5.4.  Names  enclosed  by  circles 
denote  the  states  of  the  machine;  two  concentric  circles 


TABLE  5.2  CHARACTER  CLASSES  FOR  NOPAL  LANGUAGE 


CLASS 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 


CHARACTER  SET 
OTHERS 
(BLANK) 

A,B , . . Y , Z @ $ 
0 , 1 , . . 9 

t 

< , > 

* 

/ 


EXPLANATION 


BLANK 

ALPHABETS  AND  @ $ 

DIGITS 

QUOTE 

BRACKETS 

STAR 

NEGATION 

SLASH 

PLUS 

LOGICAL  OPERATORS 
MINUS 
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Indicate  the  final  stite  in  which  the  lexical  analyzer 
sets  the  type  and  length  of  the  current  token  and  then 
returns  to  the  caller  (namely,  takes  Action  3 of  Table 
5.3).  A directed  link  shows  the  transition  from  a state 
to  another  after  an  input  character  is  read.  A notation 
a/6  is  placed  alongside  the  link.  The  a before  the  slash 
indicates  the  character  class  of  next  input  character 
as  shown  in  Table  5.2.  The  6 after  the  slash  specifies 
the  action  to  be  taken  before  the  machine  changes  to  the 
next  state  pointed  by  the  arrow.  For  example,  (2,3)/2 
says  that  if  the  next  input  character  is  of  class  2 
(an  alphabet)  of  class  3 (a  digit),  it  takes  action 
2 (which  turns  out  to  concatenate  the  character  to  the 
current  token)  and  goes  to  the  next  state.  negation 
sign  ( — I ) may  appear  before  the  character  classes  to 
indicate  the  negated  input  condition.  For  instance,  — i 
(2,3)/4  says  that  if  the  next  input  character  is  neither 
an  alphabet  nor  a digit,  takes  the  action  4 (which 
turns  out  to  decrement  the  input  pointer)  and  then  goes 
to  the  next  state.  Table  5.3  summarizes  the  actions 
taken  by  the  lexical  analyzer. 

The  NOPAL  lexical  analyzer  (LEX  or  SCAN)  is  called 
by  SAP  or  by  a recognizer  routine  whenever  a token  is 


TABLE  5.3  ACTIONS  TAKEN  BY  LEXICAL  ANALYZER  OF  NOPAL  PROCESSOR 


ACTION  1: 


ACTION  2: 


ACTION  3: 


ACTION  4i 


Set  next  character  (C)  to  lexical  token  buffer 
(LEXBUFF)  , i.e.,  LSXBUF  C ; 

Concatenate  current  character  to  current  token 
i.e.,  LEXBUFF  t-  LEXBUFF  1|  C ; 

Set  the  type  and  length  of  the  current  token; 
return ; 

Decrement  current  input  pointer,  i.e., 
backtrack  one  character; 


ACTION  5; 


Take  no  action 


r 


I 


required,  using  one  of  the  two  functionally  equivalent 
calling  sequences: 

CALL  LEX;  o^ 

IF  LEXABLE  THEN  CALL  SCAN; 

where  LEXABLE  is  an  external  1-bit  flag  indicating  the 
current  enab led /disab led  status  of  the  lexical  analyzer. 
The  second  calling  sequence  should  be  preferred  since 
it  actually  invokes  the  lexical  analyzer  only  if  the 
analyzer  is  enabled,  while  the  first  sequence  always 
invokes  the  analyzer.  This  should  somewhat  speed  up 
the  lexical  scanning  of  the  NOPAL  because  the  lexical 
analyzer  must  be  invoked  so  many  times  in  the  SAP 
and  in  the  recognizer  routines  and  because  the  PL/I 
procedure  invocations  need  time  consuming  prelogues 
and  epilogues  [IBM  72].  When  the  lexical  analyzer  is 
invoked,  it  first  "disables"  itself  by  setting  the  flag 
LEXABLE  to  false  (the  returned  value  will  always  be  the 
token  until  the  lexical  analyzer  is  enabled  explicitly 
and  called  again).  It  then  scans  the  input,  extracts 
a token,  and  returns  to  the  caller  the  following  three 
items  (as  external  variables); 

(1)  LEXBUFF  --  the  current  token  itself; 

(2)  LEXLEN  --  the  length  (number  of  characters) 
of  the  token;  and 
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(3)  LEXTYP  --  the  type  of  the  token.  Seven 
types  have  been  defined: 

1)  $SP:  special  characters,  e.g. 

(.*,/ 

2)  $L;  logical  operators,  e.g. 

& , ! . ? 

3)  $A:  alphameric  identifiers, 

e.g.  A5_K,  XYZ 

4)  $D : unsigned  integers,  e.g.  1, 

345 

5)  $BIT:  bit  strings,  e.g.  'lOOl'B 

6)  $CHAR:  character  strings,  e.g. 

'XYZ',  '123' 

7)  $REL:  relational  operators, 

e.g.  - , < 

The  lexical  analyzer  must  be  explicitly  enabled  by  the 
calling  SAP  or  recognizer  routine,  using  one  of  the 
following  two  equivalent  statements; 

CALL  LEXENAB;  ox 

LEXABLE  » 'I'B; 

LEXENAB  is  an  entry  in  the  lexical  analyzer  which  simply 
sets  the  flag  LEXABLE  to  true  when  called.  Again,  the 
second  assignment  statement  should  be  preferred  to  the 
first  call  statement  for  better  efficiency. 
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In  addition  to  LEX  (or  SCAN)  and  LEXENAB;  the 


NOPAL  lexical  analyzer  provides  the  following  entry 
points  for  other  services. 

GETEXT : a utility  to  get  the  text  of  a character 

string . 

STMT_FL:  a housekeeping  routine  to  skip  input 

characters  until  the  next  semicolon  (;) 
and  reset  the  states  for  the  SAP;  called 
when  a statement  fails. 

STMTEND:  increments  statement  number  counter  and 

checks  the  statement  and  marker  ( ; ) . 

WARN:  issues  warning  message  during  syntax 

analysis  . 

LASTREC:  prints  last  record  of  source  input. 

POSNUMB:  unsigned  number  recognizer  routine. 

In  conclusion,  the  lexical  analyzer  scans  the  source 
input  string  and  returns  a token  to  the  calling  SAP  or 
recognizer  routine.  As  a by-product,  a source  specifi- 
cation report  in  which  the  source  statements  are  listed 
with  statement  numbers  is  produced.  The  NOPAL  lexical 
analyzer  should  be  more  efficient  than  that  of  the  DDL 
or  the  MODEL  due  to  the  following  reasons;  (1)  As 
indicated  in  Figure  5.4,  the  NOPAL  lexical  analyzer  is 
implemented  in  a way  that  each  class  of  tokens  can  be 
considered  as  a small  finite  state  machine.  Characters 
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before  the  current  one  can  be  "remembered",  and  it 
always  returns  good  tokens  without  the  need  for 
further  checking.  (2)  It  provides  ways  of  avoiding 
unwarranted  invocations  of  PL/1  procedures.  (3)  In 
addition  to  the  token  itself,  it  also  provides  the 
type  and  the  length  of  the  token. 

5.3.2  ERROR  MESSAGE  STACKING  ROUTINES 

This  section  describes  the  subroutines  which  place 
codes  of  error  messages  on  a push-down  stack  upon 
recognition  of  incorrect  syntactic  units  in  NOPAL  state- 
ments. SAP  neither  generates  nor  prints  its  own  messages 
automatically.  However,  it  expects  the  corresponding 
diagnostics  to  be  placed  on  an  "error  stack"  by  the 
routines  provided  by  the  language-def iner . During  the 
syntax  analysis,  if  the  expected  token  is  successfully 
recognized,  SAP  simply  pops  the  corresponding  error 
message  code  and  continues.  If  the  expected  token  is 
missing  or  incorrect,  SAP  prints  the  statement  number  and 
the  corresponding  error  message  which  are  on  top  of 
the  error  stack,  it  then  pops  the  error  message  from  the 
stack,  scans  for  the  statement  end  marker  (;)  and  then 
continues.  The  error  message  stacking  routines,  the 
error  codes,  and  their  meanings  are  listed  in  Table  5.4. 


TABLE 

5 . 4 ERROR 

STACRiNG  RuU'liNEb,  ERRUK  CODES,  AND  MESSAGES 

NAME 

CODE 

MESSAGE 

ARGSUBS 

AX-ARG 

missing/invalid  argument  of  function 

call  or  subscript  of  a subscripted 

variable 

ASRTl  ' 

NOCOLN 

missing  colon  ' : ' 

ASRT3 

AS-REL 

missing  relational  operator  in  an 

assertion 

AXERl 

AX-BAD 

missing/invalid  arithmetic  expression 

NORPAR 

missing  right  parenthesis  ' ) ' . 

BXERl 

BX-REL 

missing  relational  operator  in  a 

boolean  expression 

BXER2 

BX-BAD 

missing/invalid  boolean  expression 

BXLPAR 

missing  left  parenthesis  ' { ' after 

negation  ' , ' 

BXRPAR 

missing  right  parenthesis  ' ) ' . 

CDERl 

CDE-ID 

missing/invalid  connector  id  in  conn_ 

dim_ex 

CDER2 

CDENO> 

missing  right  triangular  bracket  '>' 

in  conn_dim_ex 

CMNPSFF 

DGCMPF 

missing/invalid  affected  component 

CMPSL0P 

DG-LOP 

and  ' 1 ' operators  mixed 

DGCMPF 

missing/invalid  affected  component 

COLON 

NOCOLN 

missing  colon  ' : ' . 

CONJ5 

CJ-REL 

missing  relational  operator  in  a 
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TABLE  5.4  (continued)  / 

NAME  CODE  MESSAGE 

conjunction 

NORPAR  missing  right  parenthesis 

DCLERl  DCL-ID  missing  variable  ID  in  declaration 

DIAGER2  NO-MSG  missing  'MESSAGE'  after  'OPERATOR' 

in  keyword  diagnosis  definition 
NOCOLN  missing  colon  ':'  after  'OPERATOR 

MESSAGE'  in  keyword  diagnosis 
definition 

DIAGl  DG-LBL  missing  diagnosis  label 

FDERl  FDEBAD  mi s s i ng/ i nval id  function  dimension 

expression 

FDRPAR  missing  right  parenthesis  in 

f unc-dim-ex 

FNERl  FNTYPE  mi s sing/ inval id  function  type 

GETASRT  AS-BAD  mi s s i ng/ i nval id  assertion 

IFCOND  IFTHEN  missing  THEN  in  an  IF-clause 

UEYEQ  KEY-EQ  missing  equal  sign  '='  after  a 

keyword 

L0GIC2  LG-OPR  missing/invalid  logical  operator 

DG-LBL  missing  diagnosis  label  after  logical 

operator 


TABLE  5.4  (continued) 


1 


NAME 

CODE 

MESSAGE 

MSGERl 

MSGLBL 

missing  message  label 

MSGER2 

KEY-EQ 

missing  equal  sign  '='  after  'ALIAS 

MSNAME 

missing  message  synonym  after  '=' 

MSCOMA 

missing  comma  ' , ' after  message 

synonym 

OPMSG3 

OGMSGA 

missing/invalid  message  argument  in 

other  parameters  of  a diagnosis 

0PRPS3 

DG-VAR 

missing/invalid  operator  response 

variable  ID 

RPAR 

NORPAR 

missing  right  parenthesis  ' ) ' 

SAMEl 

BR-LBL 

missing/invalid  back-reference 

stim/meas  lable 

SPECERR 

SP-BAD 

invalid  specification  statement 

TBLERl 

KEYBAD 

missing/invalid  keyword 

KEY-EQ 

missing  equal  sign  '='  after  a 

keyword 

KEYTXT 

missing/invalid  text  after  '=' 

TBLER2 

NO-ID 

missing  identifier 

TSMERl 

TSM-ID 

missing  parent  label  after  ' ( ' 

NORPAR 

missing  right  parenthesis  ')  ' 

TXTBAD 

MSGTXT 

missing/invalid  message  text 
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5.3. 2.1  WHERE  THE  ERROR  MESSAGE  STACKING  ROUTINES 
ARE  USED 

Preceding  every  required  terminal  symbol  or  non- 
terminal associated  with  a recognizer  routine  in  the 
EBNF/WSC  production  rules  of  NOPAL,  a routine  name  must 
be  inserted  to  stack  an  error  message  code  in  case  the 
token  is  missing  or  incorrect.  A non-terminal  associated 
with  a recognizer  routine  is  a non-terminal  which  is 
eventually  defined  to  reference  a recognizer  routine 
(recognizer  routines  and  non-terminals  associated  with 
them  are  further  discussed  in  Section  5.3.3).  To 
illustrate,  consider  the  EBNF  statement  102  of  Figure 
3 . 1: 

< MESSAGE_DEFINITION  MESSAGE  < MESSAGE_LABEL  >[:] 

[ALIAS  - < SYNONYM  >,]  [TEXT  - ] < MESSAGE_TEXT  >: 

The  corresponding  production  rules  in  the  EBNF/WSC  of 
NOPAL  (lines  146-151,  3,  and  59  of  Figure  5.2)  become: 

< MESSAGE_DEFINITION  > ::»<  MESSAGE  >/MSGERl/ 

< MESSAGE_LABEL  > 

/SVLBL/  [:]  [ALIAS/MSGER2/  - < SYNONYM  >/SVSYN/,] 

[TEXT/KEYEQ/  - ] < MESSAGE_TEXT  >/STMSG/  /STMTEND/ 

< MESSAGE  >::»  /MESSAGE/ 

< SYNONYM  >::»  < IDENTIFIER  > 

< LABEL  > : : - /LABEL/ 

< IDENTIFIER  > /NAMEREC/ 

■>..MESSAGE_LABEL  > < LABEL  > 


1 /.  o 


0 


In  the  above  example,  < MESSAGE  >,  < MES SAGE_LAB EL  > , 

and  < SYNONYM  > are  non-terminals  associated  with  the 
recognizer  routines  MESSAGE,  LABEL,  and  NAMEREC 
respectively.  MSGERl,  MSGER2,  and  KEYEQ  are  error 
message  stacking  routines.  The  two  non-terminals 
< MESSAGE_LABEL  > and  < SYNONYM  >,  and  the  three 
terminals  and  another  "="  are  mandatory,  and 

hence  the  corresponding  five  error  message  codes  are 
required  in  this  production  rule.  The  routine  MSGERl 
has  been  inserted  before  < MESSAGE_LABEL  > to  stack 
the  missing  message  label  error;  the  routine  MSGER2 
has  been  inserted  after  the  first  element  ALIAS  of  an 
optionality  group  to  stack  three  error  messages  for  the 
three  corresponding  non-optional  symbols  < SYNONYM  > 

and  The  third  error  stacking  routine  KEYEQ  stacks 

an  error  message  for  the  mandatory  equal  sign 
after  the  keyword  TEXT  in  another  optionality  group. 

Note  that  no  error  messages  have  been  stacked  for  non- 
terminals such  as  < MESSAGE_TEXT  > in  the  above  pro- 
duction. An  appropriate  error  message  for  each  non- 
optional  terminal  symbol  or  non-terminal  associated  with 
a recognizer  routine  is  expected  to  be  stacked  in  the 
lower-level  grammar  tree  such  as  the  production  rule 
for<  MESSAGE  TEXT  >.  Note  also  that  there  is  no  error 
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message  stacked  for  the  very  first  element  of  an 
optlonality  group.  Similarly  of  a production,  unless 
the  production  is  mandatory. 

5.  3.  2. 2 HOW  TO  WRITE  ERROR  MESSAGE  STACKING  ROUTINES 
Error  message  stacking  routines  have  the 
following  general  form  in  the  current  NOPAL  imple- 
mentat ion : 

< ROUTINE_NAME  >:  PROCEDURE; 

DCL  ERRORS(n)  CHARACTER(6)  STATIC  INITIAL 

i ^ n 

CALL  $PUSH(ERRORS) ; 

RETURN; 

END  < R0UTINE_NAME  >; 

Where  < ROUjriNE_NAME  > is  the  name  of  an  error 

message  stacking  routine,  n(  > 1)  is  the  total  number 

of  error  codes  to  be  stacked  in  this  routine,  and  c^, 

c-,...,  c are  the  actual  error  codes  of  six  characters 
^ n 

each.  Note  that  the  codes  will  be  pushed  down  the 
error  stack  in  the  reverse  order  that  they  appear.  That 
is,  Cj^  will  be  at  the  bottom,  while  c^^  at  the  top.  For 
the  two  error  stacking  routines  MSGERl  and  MSGER2  in  the 
above  example,  the  corresponding  PL/I  codes  become: 
MSGERl:  PROCEDURE; 

DCL  MSGLBL(l)  CHAR(6)  STATIC  INIT ( ' MSGLBL  ' ) ; 


> t 


0 
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CALL  $PUSH (MSGLBL) ; 


RETURN ; 

END  MSGERl;  and 

MSGER2:  PROCEDURE 

DCL  MSGERRO)  CHAR(6)  STATIC  INIT 
('KE.Y-EQ',  'MSNAME',  'MSCOMA'); 

CALL  $PUSH(MSGERR) ; 

RETURN; 

END  MSGER2; 

5.3.3  RECOGNIZER  ROUTINES  -- 

A recognizer  routine  is  a PL/I  procedure  which 
recognizes  a certain  class  of  tokens  from  the  input 
string.  It  is  a function  which  returns  a 1-bit  value 
of  1 or  0,  representing  true  or  false  respectively, 
depending  upon  the  success  or  the  failure  of  recognition. 
Recognizer  routines  are  primarily  used  to  speed  up  the 
recognition  process  of  SAP;  they  are  often  employed  when 
it  would  be  clumsy  and  time-consuming  to  have  SAPG 
generate  necessary  code  to  do  the  required  analysis.  For 
example,  to  recognize  a character  string  as  an  identifier 
(i.e.,  a name)  the  following  two  EBNF  productions 
(statements  18  and  19  of  Figure  3.1)  could  be  directly 
used  in  the  EBNF/WSC: 


< IDENTIFIER  > ; ; - < LETTER  > [ < TAIL  > ] * 

< TAIL  > < LETTER  > | < DIGIT  > 

* 

It  would  require  as  many  iterations  as  the  number  of 

characters  in  the  name.  Instead,  a recognizer  NAMEREC 

has  been  used  (in  the  third  line  < IDENTIFIER  > 

/NAMEREC/  of  the  EBNF/WSC)  to  analyze  it  in  a 

single  pass  and  even  to  check  the  length  of  the  name. 

NOPAL  keywords  consisting  of  more  than  five  characters 

are  also  implemented  as  recognizers,  each  of  which 

recognizes  as  a good  keyword  a set  of  all  names  having 

the  same  prefix  of  four  characters.  All  recognizer 

routines  in  the  NOPAL  are  enumerated  in  Table  5.5. 

5. 3. 3.1  HOW  TO  DENOTE  AND  REFERENCE  RECOGNIZER  ROUTINES 
IN  EBNF/WSC 

Given  a production  rule  "L  R" , the  non-terminal 

L is  called  the  left-part  of  the  production;  the  R, 
consisting  of  one  or  more  terminals  or  non-terminals, 
is  called  the  right-part  of  the  production.  If  R is  a 
non-terminal  alone,  the  production  is  a singular 
production. 

A recognizer  routine  is  represented  by  an  EBNF/WSC 
production  which  involves  a stand-alone  subroutine  call 
as  the  right-part,  i.e.,  a production  called  recognizer 
production,  of  the  following  general  form; 

< L > : /RECOGNZ/ 


where  < L >is  a non-terminal  and  RECOGNZ  is  the  name  of 


TABLE  5.5  RECOGNIZER  ROUTINES  WITH  EXAMPLES 


NAME 

WHAT  IT  RECOGNIZES 

EXAMPLES 

ANDOROP 

AND  (&)  and  OR  ( 1 ) 

logic  operators 

1 

ARROW 

Arrow  (-♦■) 

CHARSTR 

Character  strings 

■XYZ  ' , ’ 101  ' 

DIMREC 

Dimensions  (units) 

VOLT,  OHM 

EXPONET 

Exponentiation  operator  (**) 

* * 

INTEGER 

Integers  (signed  or  unsigned) 

12,  +34,  -56 

LABEL 

Labels  (identifiers  or 

unsigned  integers) 

A1_J,  345 

LOGICOP 

NOPAL  logical  operators 

&,  1 1 

NAME REG 

Identifiers 

§X2_B,  XYZ 

NUMBER 

Numbers  (signed  or 

unsigned ) 

3.5,  -l.OE+70 

OR_OP 

OR  ( 1 ) logic  operator 

1 

PLUSMIN 

Range  operator  (+-) 

+ - 

POSTINC- 

Unsigned  integers 

1234 

POSNUMB 

Unsigned  numbers  ' 

12,3.5,1.  OE-7 

RELREC 

Relational  operators 

\ A 

II 

II 

V 

11 

STRREC 

String  constants  (character 

or  bit) 

'XYZ',  'lOl'B 

TIMEEDM 

Time-dimensions 

MIN,  SEC,  MSE 
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TABLE  5.5  (continued) 


The  following  are  NOPAL  keyword-stem  recognizers.  If 


a keyword 

is  more  than  five  charac 

ters  long,  only  the  first 

four  characters  will 

suffice  . " . . 

."  denotes  zero  or  more 

alphameric 

characters  . 

NAME 

WHAT  IT 

RECOGNIZES 

EXAMPLES 

ASSERT 

ASSE . . . , 

ASRT  . . . 

ASSERTION , ASRT , ASSE 

ATE_PNT 

ATE_.  . . 

ATE_POINT , ATE_PT , ATE_P 

COMMENT 

COMM  . . . 

COMMENTS,  COMM 

COMPFL 

COMP  . . . 

COMP_FAIL, COMP , COMPONENT 

CONJUNC 

CONJ  . . . 

CONJUNCTION,  CONJ 

CONNECT 

CONN  . . . 

CONNECTION,  CONN, 

CONNECTORS 

COOPERA 

COOP  . . . 

COOPERATION,  COOP 

3IAGNOS 

DIAG  . . . 

DIAGNOSIS,  DIAG 

EXCEPT 

EXCE  . . . 

EXCEPT,  EXCE 

FAILURE 

FAIL  . . . 

FAILURE,  FAIL 

FUNCTION 

FUNC  . . . 

FUNCTION,  FUNC 

MEASURE 

MEAS  . . . 

MEASUREMENT,  MEAS 

MESSAGE 

MESS  . . . 

MESSAGE,  MESS 

PARAMET 

PARA.  . . , 

PARM  . . . 

PARAMETER,  PARM,  PARA 

PROTECT 

PROT . . . 

PROTECTION,  PROT 

RESPONS 

RESP  . . . 

RESPONSE,  RESP 

SPECIF 

SPEC  . . . 

SPECIFICATION,  SPEC 
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TABLE  5.5  (continued) 


NAME 

WHAT  IT  RECOGNIZES 

EXAMPLES 

SRC_TGT 

SOUR. . . jTARG . . . 

SOURCE,  SOUR:TARGET, 

TARG 

STIMULI 

STIM. . . 

STIMULI,  STIM,  STIMULUS 

UUT_PNT 

UUT_. . . 

UUT_POINT , UUT_PT , UUT_P 

1 

J 


the  recognizer  routine  to  be  called.  In  other  words, 
if  a subroutine  call  appears  in  a production  as  the 
right-part,  the  subroutine  is  a recognizer  routine.  For 
example,  the  NAMEREC  is  a recognizer  routine  in  the 
following  production; 

< IDENTIFIER  /NAMEREC/ 

There  is  a class  of  non-terminals  which  are 
associated  with  a given  recognizer  routine.  A non- 
terminal < N >is  said  to  be  in  this  class  if  < N >is 
the  left-part  of  the  recognizer  production,  or  recursively 

< N >is  the  left-part  of  a singular  production  whose 
right-part  is  a non-terminal  in  this  class.  In  other 
words,  a non-terminal  is  said  to  be  associated  with  a 
recognizer  routine  if  it  is  eventually  defined  to 
reference  the  recognizer  routine.  For  example, 

< SYNONYM  > and  < IDENTIFIER  > in  the  following  two 
productions  are  both  associated  with  the  recognizer 
routine  NAMEREC. 

< SYNONYM  > < IDENTIFIER  > 

< IDENTIFIER  > /NAMEREC/ 

As  far  as  error  message  stacking  is  concerned,  non- 
terminals associated  with  recognizer  routines  play  the 
same  role  as  terminal  symbols  do,  hence  they  are  treated 
exactly  in  the  same  way  in  preparing  EBNF/WSC. 
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5. 3.3.2  HOW  TO  WRITE  RECOGNIZER  ROUTINES 


Recognizer  routines  are  PL/I  procedures  which 
return  a bit  string  of  length  1.  They  must  perform 
the  necessary  lexical  functions  that  SAP  does.  Nor- 
mally, upon  entry  to  such  a routine,  the  lexical 
analyzer  (LEX  or  SCAN)  is  called  to  get  a lexical  unit 
(token)  to  be  analyzed.  More  than  one  token  may  need 
to  be  obtained  to  complete  analysis.  After  the  necessary 
analysis,  if  recognition  is  successful,  the  lexical 
analyzer  must  be  "enabled"  by  setting  LEXABLE  to  'I'B 
(or  calli.ng  LEXENAB,  see  Section  5.3.1)  and  'I'B  (true) 
must  be  returned.  Otherwise,  'O'B  (false)  must  be 
returned . 

As  indicated  in  Section  5.3.1,  in  addition  to  the 
token  available  in  LEXBUFF,  the  type  and  the  length 
of  the  token  are  also  available  in  LEXTYPE  and  LEXLEN 
respectively.  Seven  token  types  are  defined  in  NOPAL. 
Three  entry  points  LEX,  SCAN  and  LEXENAB,  and  a lock 
switch  LEXABLE  are  defined  in  the  lexical  analyzer 
(see  Section  5.3.1).  All  of  these  are  PL/I  external 
variables,  and  hence  can  be  accessed  for  analysis  in 
preparing  recognizer  routines.  To  illustrate  these 
features,  the  recognizer  routine  NAMEREC  appears  as 
f o Hows  : 


157 


NAMEREC:  PROCEDURE  RETURNS  (BIT(l)); 

DCL  LEXBUFF  CHAR(31)  VAR  EXT,  /*  TOKEN  BUFFER  */ 
(LEXTYP,  LEXLEN)  FIXED  BIN  EXT, 

/*  TOKEN  TYPE  & LENGTH  */ 

LEXABLE  BIT(l)  EXT,  /*  LEX  lock  switch  */ 

$A  FIXED  BIN  EXT;  /*  TOKEN  TYPE:  ALPHAMERIC  */ 
DCL  (T  INIT('l'B),  F INIT('O'B))  BIT(l)  STATIC; 

IF  LEXABLE  THEN  CALL  SCAN;  /*  OR  CALL  LEX:  */ 

IF  LEXTYP  - $A  THEN  RETURN(F); 

IF  LEXLEN  > 12  THEN 
DO;  LEXLEN  - 12; 

LEXBUFF  - SUBSTR(LEXBUFF,  1,  LEXLEN); 

CALL  WARNC,  NAME/INTEGER  TOO  LONG. 

TRUNCATED. ' ) ; 

END; 

LEXABLE  - T;  /*  ENABLE  LEX;  OR  CALL 

LEXENAB;  */ 

RETURN (T) ; 

END  NAMEREC; 

The  first  two  statements  are  variable  declarations. 
Then  the  routine  calls  the  lexical  analyzer,  via  entry 
SCAN,  to  get  a token.  If  the  token  is  not  alphameric 
then  F(false)  is  returned.  Otherwise,  it  continues  to 


check  the  length  of  the  token  to  be  no  greater  than  12. 


r 

Finally,  the  lexical  analyzer  is  enabled  and  T(true) 

' is  returned. 

5.3.4  ENGODING/SAVING/STORING  ROUTINES 

Encoding /saving  routines  are  used  to  encode  some 
of  the  NOPAL  syntactic  units  and  save  them  into  an 
internal  representation.  Although  some  entities  such  as 

[ 

names  provided  by  a user  are  kept  intact  in  internal  form, 
many  of  the  descriptions  and  attributes  are  encoded, 
compacted  and  saved  for  more  efficient  processing  later. 

I For  example,  there  are  fourteen  types  of  NOPAL  statements 

and  they  are  encoded  internally  as  fourteen  integers, 
i Storing  routines  are  specified  at  the  end  of  source  state- 

ments. They  gather  information  in  the  statements,  and 

1 

’ in  turn  call  the  STORE  subsystem  (to  be  discussed  in 

I Section  5.4)  to  store  the  statements  for  later  processing. 

I Each  NOPAL  statement  corresponds  a tree-like  data 

structure  (implemented  as  a PL/1  based  structure),  which 
I is  used  to  store  all  of  the  information  about  the  state- 

, ment.  The  encoding,  saving,  and  storing  routines  all 

I 

I together  are  responsible  for  creating  such  statement  data 

structures,  collecting  and  filling  in  all  the  Information, 
and  passing  them  to  the  STORE  subsystem  to  update  the 
directory  and  properly  link  the  storage  keys  for  accessing 
the  statements.  The  data  structure  of  all  NOPAL  state- 
ments in  conjunction  with  the  corresponding  PL/1  based 
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structure  declarations  are  presented  in  Appendix  A. 

The  STORE/RETRIEVE  subsystem  is  discussed  in  Section  5.4. 

The  encoding,  saving  and  storing  routines  are  summarized 

in  Table  5.6  in  the  groups  of  statements. 

5. 3.4.1  WHERE  THE  ENCODING/SAVING/STORING  ROUTINES  ARE 
USED  IN  EBNF/WSC 

The  encoding  and  saving  routine  names  are  inserted 
in  the  EBNF/WSC  statements  whenever  there  is  a need  to 
encode  and  save  a syntactic  unit  for  later  storing. 

Each  routine  is  automatically  invoked  by  SAP  after  the 
successful  recognition  of  the  syntactical  unit  immediate- 
ly preceding  the  routine  call.  A storing  routine  name 
is  inserted  at  the  end  of  each  NOPAL  statement  to  collect 
the  information  about  the  statement  and  to  invoke  the 
STORE  routine  of  the  STORE /RETRIEVE  package  for  storing 
the  statement.  To  illustrate,  take  the  following  EBNF/ 
WSC  statement  (line  51  of  EBNF/WSC  for  NOPAL): 

[NOPAL]  < SPECIFICATION  > [ < SPEC_NAME  >/SVLBL/]/ 

/STSPEC/ 

where  < SPECIFICATION  > is  associated  with  a recognizer 
for  keyword  SPECIFICATION;  < SPEC_NAME  > is  associated 
with  a recognizer  /or  a label  (in  this  case,  a name  for 
NOPAL  specification)  (see  lines  57  and  58  of  the  EBNF/ 
WSC).  The  SVLBL  subroutine  call  is  inserted  immediately 
after  SPEC  NAME  ^ in  order  to  save  the  label. 
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TABLE  5.6 


ENCODING,  SAVING,  AND  STORING  ROUTINES 


1 . 


2 . 


3 . 


STATEPT 

“ — — 

Stores  ATE_CONNECTION_POINT  statement 

SCOMPT 

— 

Saves  comment 

SVPTID 

— 

Saves  matching  UUP_POINT  ID's 

SVSEQ# 

— 

Saves  internal  table  entry  sequence 

number 

SVSYN 

— 

SAVES  synonym  of  the  ATE  connecting 

point  ID 

SVLBL 

— 

Saves  ATE  connecting  point  ID 

STCOMP 

— 

Stores  component/failure  statement 

SVPARML 

— 

Saves  parameter  list  of  failure  function 

SCOMT 

— 

Saves  comments 

FLSFF 

— 

Saves  failure  function 

FLSIDX 

— 

Saves  failure  index 

SVCMPFL 

— 

Saves  component  failure  seq#  for 

component  protection 

SVLBL 

— 

Saves  the  sequence  number  for  this 

component  failure 

UUTCMPF 

— 

Allocates  component-fail  entry  and  saves 

component  ID 

SVSYN 

— 

Saves  synonym  of  the  component  ID 

PMSID 

— 

Saves  parameter  ID 

■1 

Stores  diagnosis  statement 

STDIAG 

— 

DIAGl 

— 

Allocates  and  initializes  the  diagnosis 

entry 
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TABLE  5.6  (continued) 
Saves  diagnosis  label 


f 

\ 


I 


i 

f 


i 

t 


i 


5. 


SPARM 

- — 

Saves 

other  parameters 

CMPRLOP 

— 

Allocates  entry  for  affected  components 

CMPSID 

--- 

Initiates  and  saves  components 

SVCMPFIi 

— 

Saves 

component-failure  sequence  number 

MASTR 

— 

Saves 

message  parameter:  string  constant 

CMPSLOP 

— 

Saves 

Logical  operator  (&  or  |) 

MANUM 

— 

Saves 

message  parameter:  number 

MAVAR 

— 

Saves 

message  parameter:  variable 

OPRPSl 

— 

Saves 

operator  response  Y/N  (i.e.,  ?) 

OPRPS2 

— 

Saves 

variables  of  operator  response 

TIMEl 

— 

Saves 

value  of  timing 

TIME2 

— 

Saves 

dimension  of  timing 

STYP 

— 

Saves 

message  type 

STEND 

— 

Store 

END  statement 

SVLBL 

— 

Saves 

label 

STFUNC 

— 

Store 

s ATE__function  statement 

SVSEQ# 

— 

Saves 

internal  table  entry  sequence 

number 

SVSYN 

— 

Saves 

synonym  of  ATE  function  ID 

FNSTYP 

— 

Saves 

function  type 

ATEFUNC 

— 

Allocates  function  entry  and  saves 

function  ID 
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TABLE  5.6  (continued) 

FN#PINS 

— 

Saves  number  of  connecting  pins  of 

S/M  functions 

FNSVAL 

— 

Saves  values  returned 

PMSTYP 

— 

Saves  parameter  type 

FNSCF 

— 

Saves  cooperation  functions 

SCOMPT 

— 

Saves  comments 

STLOG 

— 

Stores  logic  statement 

SVLBL 

— 

Saves  label 

SVLBL2 

— 

Saves  label  (secondary)  of  the  parent 

test  module 

LOGID 

— 

Saves  logic  entry  ID 

SLOPLBL 

— 

Saves  logical  operator  and  diagnosis 

label 

STMEAS 

— 

Stores  measurement  statement 

SVLBL 

— 

Saves  label  (primary)  of  the  measurement 

SVLBL2 

— 

Saves  label  (secondary)  of  the  parent 

test  module 

STMSG 

— 

Stores  message  statement 

SVLBL 

— 

Saves  label 

SVSYN 

— 

Saves  Synonym  of  the  message  label 

TXTCH 

— 

Saves  character-string  message  text 

STSPEC 

— 

Stores  specification  statement 

SVLBL 

_ — — 

Saves  label 

10.  STSTIM 


SVLBL 


SVLBL2 


STTEST 


SVLBL 


TABLE  5.6  (continued) 

Stores  stimuli  statement 

Saves  label  (primary)  of  the  stimuli 

Saves  label  (secondary)  of  the  parent 


test  module 


Stores  test  statement 


Saves  label 


STUUTPT  Stores  UUT-connection-point  statement 


SVSEQ# 


Saves  internal  table  entry  sequence 


number 


SYSYN 


Saves  synonym  of  the  UUT  connecting 


point  ID 


SVCNTYP 


Saves  connector  type 


SVCNPT 


Saves  connector  point 


GETLMT 


Gets  protective  limit  entry 


PMSDM 


Saves  parameter  dimension 


PMSHL 


Saves  upper  limit  of  parameter 


PMSLL 


Saves  lower  limit  of  parameter 


PMSRPT 


Saves  parameter  reference  point 


SCOMT 


Saves  comments 


PMSID 


PMSTY 


Saves  parameter  ID 
Saves  parameter  type 


UUTPNT 


Allocates  UUT  point  entry  and  saves  UUT 


point  ID 


STWAVFM 

CONJl 

SVLBL 

SVLBL2 

STRIPT 

CONJ5 

CJSFDE 

BRSLBL 

DCLSVAR 

DCLSUBS 

DCLSID 

CDESID 
CDESDM 
FOES DM 

FDESl 

SETFDE 

FDESFDE 

FDESMOD 


♦ 

V 

TABLE  5.6  (continued) 

Stores  conjunction  waveform 

Allocates  conjunction  entry  and  stores 

conjunction  label 

Saves  label  (primary)  of  the  conjunction 
Saves  label  (secondary)  of  the  parent 
stimuli  or  measurement 

Allocates  and  saves  simple  conjunction 
Allocates  connector  entry 
Saves  function-dimension-expression 
Saves  back  reference  label  for 
conjunction 

Saves  a variable  in  variable-declaration 

Saves  subscripts  of  variable-declaration 

Saves  and  verifies  the  IDs  of  variable- 

declaration 

Saves  connector  ID 

Saves  connector  dimension 

Saves  dimension  in  function-dimension- 

expr 

Saves  a token  in  func-dim-ex 
Gets  a stack  for  new  func-dim-ex 
Saves  a nesting  func-dim-ex 
Save  modifier  for  func-dim-ex 
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TABLE  5.6  (continued) 

STWAVFM  Stores  assertion  waveform 

ASRTl  Allocates  assertion  entry  and  stores 

assertion  label 

SVLBL  Saves  label  (primary)  of  -the  assertion 

SVLBL2  Saves  (secondary)  of  the  parent  stimuli 

or  measurement 

ASEXPS  Saves  expressions  before  and  after  the 

relational  operator  of  an  assertion 

ASREL  Saves  relational  operator  of  an 

assertion 

ASRANGE  Saves  range  of  an  assertion 

ASPC  Sets  the  percentage  of  the  range 

DCLSUBS  Saves  subscripts  of  variable-declaration 

DCLSID  Saves  and  verifies  IDs  of  variable- 

declaration 

GETASRT  Allocates  and  saves  simple  assertion 

The  following  are  the  encoding  and  saving  routines 
which  are  used  in  arithmetic  and  Boolean  expressions. 
AREXSAV  Concatenates  an  arithmetic  sub-expression 

r 

AREXSl  Saves  a to)cen  for  arithmetic  expression 

AREXSVF  Saves  a variable  or  function  call 

SETVF  Allocates  a staclc  for  a variable  or 


function  call 


TABLE  5.6  (continued) 


VFSO 


VFSl 


VFS2 


VFSAX 


IFCOND 

SETBEXP 

BEXPSl 

8EXPSAX 


Sets  subscript  switch  and  saves  a 
token  for  variable  or  function  call 

\ 

Saves  a token  for  variable  or  function 
call 

Gets  and  saves  string  constant  for  a 
function  call 

Saves  arithmetic  expression  in  a 
variable  subscript  or  a function 
argument 

Saves  the  condition  part  of  an  IF  clause 
Allocates  a stack  for  Boolean  expression 
Saves  a token  for  Boolean  expression 
Saves  an  arithmetic  expression  in 
Boolean  expression 

I'a'is'e-  « B.'Olein  sub -ex  p r e s s lo  n 
• « - ' r ■»  r J *■  tip*  * i - 


At  the  end  of  the  statement,  STSPEC  subroutine  call 


is  Included  to  store  the  statement. 

5. 3. 4. 2 HOW  TO  WRITE  ENCOD ING/ SAVING / S TORINO  ROUTINES 

These  are  subroutine-type  PL/1  procedures  and  ought 
to  be  so  prepared.  For  each  source  statement,  a storing 
routine  and  a set  of  encoding/saving  routines  are 
required  to  allocate  data  structure,  encode  and/or  save 
necessary  information,  accumulate  names  (also  types) 
of  the  storage  keys,  and  finally  pass  these  to  the 
STORE  subsystem  for  updating  the  directory  and  storage 
entries  in  the  simulated  associative  memory.  The  STORE 
and  the  associative  memory  are  discussed  in  Section  5.4. 
For  instance,  the  two  routines  SVLBL  and  STSPEC  in  the 
above  mentioned  statement  are  as  follows: 

STSPEC:  PROCEDURE; 

DCL  SPEC#  FIXED  BIN  EXT;  /*  KEY  & STMT  TYPE:  SPEC  */ 
DCL  STMT_NO  FIXED  BIN  EXT.  /*  STMT  NO.  */ 

MXBVFP  HAH  »!■  VAK  EXT;  * TOKEN  BUFFER  */ 

' » k f • r I » T ! 

.•••  »»  •ff'TkiAxr  • 

• • » • • • • 


DEC  1 SPEC  BASED  (DP),  /*SPEC  DATA  STRUCTURE  */ 

2 TYPE  FIXED  BIN,  /*  STMT  TYPE  */ 

2 STMT#  FIXED  BIN;  /*STMT  NO.  */ 

ALLOCATE  SPEC; 

SPEC. TYPE-SPEC#;  SPEC.  STMT#  - STMT_^NO; 

IF  N#  - 1 THEN 

DO;  TYPES(l).  = SPEC#;  SPECNAM  - NAMES(l);  END; 
ELSE  D0J  N#  « 1: 

TYPES(l)  - -SPEC#;  NAMES(l)  - SPECNAM; 


END; 

CALL  STORE 
RETURN; 

SVLBL:  ENTRY; 

N#  - 1; 
RETURN; 

END  STSPEC; 


(DP)  ; 


/*  SAVE  LABEL 
NAMES  (.1)  LEXBUFF; 


*/ 


The  SVLBL  routine  simply  saves  the  label  and  sets 
the  counter  (N#)  of  storage  keys  to  1,  The  STSPEC 
routine  first  allocates  a data  structure,  encodes  the 


•catenent  type  as  SPEC*  (it  turns  out  to  be  inteaer  1. 
reprceentina  "specification"^  and  saves  the  statesienr 
number  •'’‘en,  it  he  ks  if  tn#  la-*  «. 


• • f 
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set.  The  key  type  is  set  to  SPEC//  either  way.  Finally, 
the  STORE  routine  from  the  STORE/RETRIEVE  package  is 
invoked  to  put  the  statement  in  the  simulated  associative 
memory . 

5.3.5  LOCAL  SEMANTICS  CHECKING  ROUTINES 

Some  of  the  local  semantics  of  the  NOPAL  statements 
can  be  checked  during  the  syntax  analysis  phase.  Such 
semantics  checking  routines  can  check  that  a condition, 
such  as  a range,  on  a syntactic  unit  is  locally  correct, 
something  cannot  be  done  through  syntax  specification 
only.  These  routines  do  not  and  cannot  check  the  over- 
all correctness,  consistency  or  completeness  of  the  whole 
NOPAL  specification,  a task  which  will  be  performed  by 
the  later  specification  analysis  phase  of  the  NOPAL 
processor.  To  illustrate,  part  of  a EBNF/WSC  production 
(lines  194-197),  corresponding  to  the  EBNF  statement  125 
cf  figuie  3.2  is  shown  as  follows; 

< ?ROTECTIVE_LIMITS  > ...  [ < MAX_LIMIT  >/PMSHL/] 

[. 

[ < MIN_LIMIT  >/PMSLL/] 

...  1 

It  aperlfles  the  upper  and  lower  protective  liaita  for 

• * nr.** 


•'  a ? • 1 n t 


A'rer  the  upper  llall  • HAX  L I T T ■ 


the  routine  PMSHL  is  invoked  to  save  it.  Similarly, 
after  the  lower  limit  < MIN_LIMIT  > the  routine  PMSLL 
[ is  called  to  save  it  and  at  the  same  time  to  check  it 

I to  be  no  greater  than  the  upper  limit.  The  statement 

semantics  checking  routines  are  listed  in  Table  5.7. 

5. 3. 5.1  WHERE  THE  LOCAL  SEMANTICS  CHECKING  ROUTINES 

I ARE  USED 

I ) 

1 These  routines  for  checking  local  statement  ■ 

: i 

semantics  are  optional  and  hence  at  the  discretion  of  | 

the  language  definer.  They  are  inserted  in  the  EBNF/  ! 

WSC  productions  after  the  appropriate  syntactic  units  I 

I 

so  that  upon  the  successful  recognition  of  these  units 
by  SAP,  they  are  invoked  to  check  locally  that  the  j 

' statement  semantics  is  correct.  Normally,  these  j 

routines  are  coordinated  or  even  combined  with  some  i 

encoding,  saving,  or  storing  routines.  For  instance,  ; 

in  the  above  example,  the  routine  PMSLL  is  inserted  j 

4 

i 

immediately  after  the  specification  of  lower  protective  | 

i 

limit  < MIN_LIMIT  > , first  to  save  it  and  then  to  make  ! 

sure  the  value  is  smaller  than  the  upper  limit  which 
was  saved  by  the  routine  PMSHL. 

5. 3. 5. 2 HOW  TO  WRITE  LOCAL  SEMANTICS  CHECKING  ROUTINES 


TABLE  5.7  LOCAL  SEMANTICS  CHECKING  ROUTINES 


NAME 

CJREL 

CKSTR 

CMPSLOP 


DCLSID 

INTEGER 

LABEL 

NAMEREC 

number 

PMSLL 


POSINTG 


WHAT  IT  CHECKS 

checks  relational  operator  is  **'  in 
connector-dimension- express  ion. 
checks  a string  constant  never  appears  in  a 
subscripted  variable. 

checks  all  logical  operators  in  the  affected 
components  of  a diagnosis  are  either  OR  (|  ) 
or  AND  (&)  but  not  mixed. 

checks  each  variable  id  in  a SOURCE  or  TARGET 
declaration  has  appeared  in  the  same 
conjunction  or  assertion  statement, 
recognizes  integers  and  checks  the  number  of 
digits  in  an  integer. 

recognizes  labels  (i.e.,  identifiers  or 
integers)  and  checks  their  length  (number  of 
characters ) 

recognizes  identifiers  (i.e.,  names)  and 
checks  their  length. 

recognizes  any  numbers  and  checks  their  length, 
saves  lower  protective  limit  for  a UUT 
connection  point  and  checks  the  lower  limit 
is  not  greater  than  the  upper  limit, 
recognizes  unsigned  integers  and  checks  their 
length 

reroKnizee  uniilfined  nuiabers  end  rhecke 
( tr  Ivneth 


information  encoded  and/or  saved  previously  by  other 
routines  may  be  accessed  for  the  purpose  of  checking 
local  semantics.  To  illustrate,  again  consider  the 
above-menti oned < PROTECTI VE_LIMITS  > example.  The 
semantics  checking  (and  also  saving)  routine  PMSLL 
appears  as  follows: 

PMSLL:  PROCEDURE; 

DCL  LEXBUFF  CHAR(31)  VAR  EXT;  /*TOKEN  BUFFER*/ 
DCL  1 LIMIT  BASED(TP),  /*  DATA  STRUCTURE  */ 

2 DIM  CHAR(12),  /*  FOR  LIMITS  */ 

2 MAX  DEC  FLOAT, 

2 MIN  DEC  FLOAT, 

2 REF_PT  FIXED  BIN; 

LIMIT. MIN  - LEXBUFF; 

IF  LIMIT. MIN  > LIMIT. MAX  THEN 
DO;  LIMIT. MIN  - - lE+75; 

CALL  WARNC,  MlN.  LIMIT  > MAX.  LIMIT  ...  '); 

END;  \ 

RETURN; 

END  PMSLL; 

The  routine  first  saves  the  lower  protective  limit 

in  a data  structure.  Then  it  compares  the  lower  limit 

«» 

with  the  upper  limit,  which  was  saved  by  another  routine 
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PMSHL.  If  the  lower  limit  were  found  greater  than  the  upper 
one,  the  lower  limit  would  be  set  to  a negative  number 
(-10**75)  and  a warning  message  would  be  sent  to  the 
user. 

5.3.6  HOUSEKEEPING  ROUTINES 

There  are  a few  "housekeeping"  type  subroutines, 
most  of  which  need  not  be  written  by  the  language 
definer  because  they  are  provided  by  the'  SAPG  system. 
However,  their  names  need  to  be  properly  included  in 
the  EBNF/WSC.  Two  of  these  subroutines  appear  in  the 
very  first  EBNF/WSC  production  of  NOPAL  (in  fact,  any 
language  using  the  SAPG  must  be  written  in  a similar 
way),  which  are  reproduced  as  folJLows; 

< N0PAL_SPECIFICATI0N  [ < N0PAL_STMTS  >/CLRERRF/]* 

/STMT_FL/ 

< N0PAL_SPECIFICATI0N  > 

< NOPAL  SPECIFICATION  > is  the  goal  symbol  of  the 
NOPaL  language.  It  is  defined  as  zero  or  more 

< NCrAL_STMTS  >,  each  of  which  turns  out  to  be  further 
defined  as  one  of  the  NOPAL  statements.  After  one  state- 
r.jrr  recognized,  the  next  statement  is  attempted;  this 


process  repeats  until  end  of  the  input  text.  SAPG 
requires  that  the  subroutine  CLRERRF  ("Clear  Error  Flag"), 


1 


which  resets  the  error  flag  for  the  generated  SAP, 


be  called  at  the  end  of  each  statement  [FRE  72].  During 
the  recognition  process,  if  none  of < NOPAL-STMTS  > 
statement  types  is  found  to  match,  the  above  production 
indicates  to  branch  to  the  other  subroutine  STMT_FL 
("Statement  Fail").  This  routine  scans  the  input  text 
for  the  statement  end  marker  (";")  and  resets  the 
conditions  for  SAP  to  begin  processing  the  next  state- 
ment. Finally,  the  < NOPAL_SPECIFICATION  > causes  SAP 
to  attempt  recognizing  the  next  statement  recursively. 
The  CLRERRF  has  been  built  in  the  FAILMAN  package  of 
the  SAPG  system  and  hence  is  always  applicable  to  all 
languages;  the  STMT_FL  has  been  written  as  an  entry  of 
the  lexical  analyzer  and  usually  need  not  be  rewritten. 
These  two  routines  appear  in  the  first  production  only, 
as  explained. 

The  next  two  housekeeping  routines  appear  else- 
where. They  have  been  implemented  as  two  entry  points 
of  the  lexical  analyzer,  but  they  are  applicable  to 
other  languages.  STEND  (on  line  56  of  EBNF/WSC)  is 
called  at  the  end  of  the  source  input  (i.e.,  after  "END" 
is  read)  to  print  the  last  record  of  input.  STMTEND 
is  invoked  after  each  NOPAL  statement  in  order  to  incre- 
ment the  statement  number  for  the  lexical  analyzer. 
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The  above  mentioned  four  subroutines  (CLRERRF, 
STMT_FL,  STEND,  and  STMTEND)  are  explicitly  inserted 
in  the  EBNF/WSC  properly-  To  be  precise,  the  SAPG- 
generated  SAP  also  uses  other  five  housekeeping  routines 
(each  one  is  prefixed  with  $MARK,  $POPF, 

"SUCCESS,  $FAIL,  and  $PUSH  [RAM  73].  Except  the  $PUSH, 
which  is  also  used  to  push  error  codes  in  error-stacking 
routines  (as  indicated  in  Section  5.3.2),  they  are  not 
useful  to,  and  should  not  concern,  the  language  definer. 
All  housekeeping  routines  with  their  functions  are 
summarized  in  Table  5.8. 

5.4  THE  STORE/RETRIEVE  SUB-SYSTEM  AND  ASSOCIATIVE  MEMORY 
5.4.1  Introduction 

In  order  to  facilitate  the  SAPG  system  with  a 
general-purpose  mechanism  for  storing  source  statements 
and  for  later  retrieval,  the  following  subsystem  has 
been  implemented  and  included  in  the  NOPAL  Processor. 

This  is  modified  from  the  MODEL'S  string  storage  and 
retrieval  subsystem  [RIN  76]  and  the  routines  are 
completely  rewritten  to  meet  NOPAL's  special  requirements 
and  to  increase  processing  efficiency.  The  subsystem 
consists  of  two  types  of  routines. 
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NAME 

CLRERRF 

STEND 

STMTEND 

STMT_FL 

$FAIL 

$MARK 


$POPF 

$PUSH 


TABLE  5.8  HOUSEKEEPING  ROUTINES 
WHAT  IT  DOES 

clear  "error"flag  for  the  SAP  after  each 
statement  to  continue  processing  next 
statement 

prints  last  record  by  calling  LASTREC  (in 
lexical  analyzer) ; is  invoked  upon  end  of 
source  input 

checks  statement  end  marker  ( ; ) and  increments 
the  statement  number;  called  at  end  of  each 
statement 

scans  for  next  statement  end  marker  ( ; ) 
and  resets  for  the  SAP;  called  when  recogni- 
tion of  a statement  fails 

prints  error  message  on  top  of  the  error 
stack  when  a local  error  occurs 
marks  the  beginning  of  errors  for  a new  pro- 
duction; called  upon  entry  to  each  production 
and  is  done  by  pushing  blank  error  code  onto 
the  error  stack 

pops  the  top  entry  of  the  error  stack;  called 
after  successful  recognition  routine 
reference 

pushes  one  or  more  error  codes  onto  the  error 
stack;  called  explicitly  from  $MARK  or  error- 
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TABLE  5.8  (continued) 


NAME 


$SUCCESS 


WHAT  IT  DOES 
stacking  routines 

restores  the  error  stack  to  the  way  it  was 
before  a production  was  invoked;  called 
upon  termination  of  a production,  successfully 
or  not. 
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A 


(1)  STORE  for  storing  source  language  strings 
gathered  during  the  phase  of  syntax  analysis; 
and 

(2)  RETRIEVE  for  retrieving  stored  source  language 
statements,  and  for  accessing  "directory 
entries";  the  former  is  through  an  entry 
RETREVS  and  the  latter  another  entry  RETREVD. 

In  the  NOPAL  system,  a "name"  (i.e.,  a string  of 
characters  to  identify  some  entity)  may  be  associated 
with  more  than  one  "type".  Basically  a tyi^e  may  be 
interpreted  to  designate  a certain  class  of  entities. 

Thus  a name  and  a type  together  uniquely  identify  an 
entity.  For  example,  a name  X of  type  2 (representing 
test  modules)  identifies  a test  module,  while  the  same 
name  X of  type  5 (representing  diagnoses)  may  also  be 
used  to  denote  a diagnosis.  There  are  sixteen  types  of 
names  and/or  statements  defined  in  NOPAL  system,  as 
enumerated  in  Table  5.9.  One  of  the  advantages  of  allow- 
ing a name  to  be  able  to  represent  multiple  types  of 
entities  is  that  the  user  has  more  freedom  in  giving  names 
as  long  as  each  name  is  unique  in  a given  class.  For 
instance,  unsigned  integers  can  be  used  as  names  in  most 
cases,  hence  the  user  may  choose  to  use  such  sequence 
numbers  to  identify  most  entities  without  inventing 


TABLE  5.9  TYPES  OF  NAMES  AND  STATEMENTS  IN  NOPAL 


m 


TYPE  # 

MNEMONIC 

CLASS  OF  ENTITIES  REPRESENTED 

1 

SPEC# 

NOPAL  specification  label/statement 

2 

TEST# 

Test  module  label/statement 

3 

STIM# 

Stimulus  label/statement 

4 

MEAS# 

Measurement  label/ statement 

5 

DIAG# 

Diagnosis  label/statement 

6 

MSG# 

Message  label/statement 

7 

LOGIC# 

Logic  label/ statement 

8 

CONJ# 

Conjunction  label/statement 

9 

ASRT# 

Assertion  label/statement 

10 

COMP# 

UUT  component  identifier  (id) 

11 

CMPFL# 

Component -failure  (i.e.  affected  component) 

id/ statement 

12 

Ul/TPT# 

UUT  connection  point  id/statement 

13 

ATEPT# 

ATE  inter-connection  point/id  statement 

14 

FUNC# 

Function  id 

15 

VAR# 

Variable  id 

16 

END#- 

End  statement 

many  names. 


Consequently  from  the  user's  point  of  view 


the  total  number  of  names  can  be  much  reduced. 

The  STORE  routine  stores  strings  in  main  memory  as 
"storage  entries"  and  builds  "directory  entries"  in  a 
directory  of  "keys " (each  is  associated  with  a name  and 
type).  By  creating  a directory  and  storage  entries, 
the  source  language  strings  are  stored  "associatively" 
in  a sense  that  they  can  be  easily  retrieved  later  based 
on  the  content.  Such  memory  is  therefore  called 
associative  memory.  In  a non-procedural  language  like 
NOPAL,  source  statements  can  be  entered  in  any  order, 

i 

hence  this  capability  of  easy  retrieval  is  very  important  j 

to  such  a language  processor.  | 

The  two  RETRIEVE  routines  provide  the  user  with 
easy  access  to  the  statement  strings,  based  on  some  keys 
and  by  traversing  the  directory  and  storage  entries.  ■ 

5.4.2  THE  DIRECTORY  AND  STORAGE  ENTRIES 

The  directory  is  a collection  of  directory  entries. 

Each  directory  entry  corresponds  to  a key  which  is  composed 
of  a name  and  type.  Such  an  entry  points  to  the  last 
storage  entry  which  contains  the  same  key.  A last-in- 
first-out  (LIFO)  linked-list  is  maintained  from  the  most 
recent  storage  entry  with  that  key  to  other  storage 
entries  containing  the  same  key.  The  major  advantage 


of  linking  storage  entries  in  LIFO  order  is  that  it 
is  much  faster  to  add  a new  storage  entry  to  the  top 
of  the  list.  There  is  no  need  to  traverse  the  list 
down  to  the  bottom  when  adding  a new  entry,  which  is 
exactly  the  case  if  the  list  were  maintained  in  first- 
in-first-out  (FIFO)  order.  The  directory  itself  is  a 
binary  tree  structure,  that  is,  each  directory  entry 
has  a "up"  pointer  and  a "down"  pointer  to  other 
entries.  Thus  the  first  key  entered  in  the  directory 
becomes  the  root  of  the  directory  tree;  the  next  key  is 
entered  "above"  (linked  via  its  "up"  pointer)  or  "below" 
(linked  via  its  "down"  pointer)  it  is  in  the  tree 
according  to  lexicographic  order,  and  so  on.  This  type 
of  directory  structure  makes  the  modifications  -of  the 
directory  and  the  searching  for  keys  more  efficient. 

Each  directory  entry  has  the  forms  as  depicted  in 
Figure  5.3(a';.  It  consists  of  four  fields  (Key-entry, 
Reflist,  Tree-link,  and  Cross-link),  where 
Key-entry  contains  a key  which  is  composed  of  two  parts, 
keyname  and  key type . Keyname  is  a variable  string  of 
up  to  12  characters,  serving  as  the  name  of  the  key. 
Keytype  is  an  integer  number  denoting  the  type  (or  class) 


^ev-antrv  ^ 


Treg-link 


Cross -link 


Keyname 


Keytype 


Reflisn 


Up 


Dovm 


Next  - 
name 


Next  - 
type 


(b)  STORAGE  ENTRY 

Keyentry(l)  Keyentry (#keys) 


FIGURE  5.5  STRUCTURE  OF  THE  DIRECTORY  AND 

STORAGE  ENTRY 
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of  the  key. 

Ref- list  is  a pointer  to  the  LIFO  llst.of  storage 
entries  containing  the  key. 

Tree-link  consists  of  and  Down  pointers  (Indices) 
to  other  directory  entries,  whose  key  names  are  up  or 
down  respectively  in  lexicographic  order.  Cross-link 
consists  of  two  fields  (Nextname  and  Nexttype)  of  link 
pointers  (indices).  Nextname  points  to  the  next 
directory  entry  which  contains  the  same  key  type. 

Nexttype  points  to  the  next  directory  entry  containing 
the  same  key  name.  Both  lists  are  kept  in  LIFO  order. 
They  are  included  in  the  directory  to  facilitate  later 
retrieval  of  all  keys  with  the  same  name,  or  all  keys 
with  the  same  type. 

The  directory  is  implemented  as  a "controlled" 
array  whose  size  can  be  dynamically  expanded  as  needed 
in  chunks  of  256  entries.  This  way  of  implementation 
speeds  up  dynamic  allocation  and  processing  of  directory 
entries.  Also  this  makes  it  possible  that  each  directory 
entry  can  contain  a variable  length  key  name  (in  PL/I-F). 

Each  storage  entry  consists  of  two  parts:  (1)  a 
list  of  keys  (and  link  pointers)  which  are  entered  in 
the  directory,  and  by  which  information  can  easily 
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be  retrieved  later; (2)  other  data  from  the  source 


language  of  the  source  statement,  although  it  is  not 
used  in  the  process  of  retrieval.  The  structure  of 
each  storage  entry  is  shown  in  Figure  5.5(b)  where 
Data  is  a pointer  to  the  other  data  of  the  source  state- 
me  nt  . 

//Keys  is  the  number  of  keys  in  this  storage  entry. 

Key  (i  - 1 to  //keys)  is  a pointer  (index)  to  the 
directory  entry  which  contains  the  key  (name  and  type). 
Next  (i  ••  1 to  //keys)  is  a pointer  to  next  storage 
entry  which  contains  the  same  key,  represented  by  key(i). 
Note  that  all  such  storage  entries  are  threaded  together 
in  a LIFO  list,  which  is  pointed  from  the  "Reflist"  of 
the  corresponding  directory  entry. 

All  types  of  storage  entries  including  other  data, 
of  NOPAL  statements  are  depicted  in  Appendix  A. 

Figure  5.6  illustrates  an  example  of  three  storage 
entries  and  a directory  consisting  of  only  four  entries 
that  have  been  entered  in  that  order.  In  the  illustra- 
tion, each  key  is  designated  by  its  key  name  and  key 
type  separated  by  a slash  (/).  There  are  four  keys 
(B/1,  B/2,  C/1,  A / 3);  hence  four  directory  entries  are 
created  in  that  order,  and  B/1  is  at  the  root  of  the 
directory  tree.  The  picture  shows  the  directory 
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and  storage  entries  with  all  links  after  the  three 
storage  entries  have  been  entered  and  created  in  that 
order . 

5.4.3  The  STORE  Routine 

The  STORE(DP)  routine  has  one  formal  parameter  DP. 
But  there  are  three  common  variables,  N#,  NAMES  and 
TYPES,  which  are  implicitly  used  in  this  routine.  DP 
is  a pointer  to  a previously  created  data  from  the  source 
statement.  N/>  is  an  integer  denoting  the  number  of  keys 
to  be  stored  in  the  storage  entry  and  to  be  updated  in 
the  directory.  NAMES  is  an  array  of  key  names,  each  is 
a var iab le- length  string  of  up  to  12  characters.  TYPES 
is  another  integer  array  of  key  types.  That  is,  the 
ith  keyt-  has  its  name  in  NAMES(i),  and  type  in  TYPES(i). 

To  be  flexible,  the  two  arrays  are  implemented  as 
"controlled"  storage  that  their  size  can  be  dynamically 
expanded  in  chunks  of  64  elements  when  needed. 

Each  invocation  of  the  STORE  routine  will  create 
a storage  entry  containing  N/i*  keys  and  update  the 
directory;  the  data  structures  have  been  depicted  in 
Section  5.4.2. 

Algorithm  5.1  shows  the  steps  of  this  STORE  routine. 
It  obtains  the  keys  (key  names  and  types)  from  the  two 
common  areas  (NAMES  and  TYPES)  and  creates  a storage 
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ALGORITHM  5.1  STORE:  SOURCE  STRING 
/*  One  parameter.  Dp:  pointer  to  other  data 
/*  ^^ote  the  follovdng  three  external  variables: 

N#  = no.  of  keys  to  be  stored, 

NAMES(i)  = ith  key  name; 

TYPES(i)  = ith  key  type: 

/*  #NODES  = current  no.  of  directory  entries 
SI:  Allocate  a storage  entry; 

Set  DATA  pointed  of  the  storage  entry  to  Dp. 

S2:  /*  Check. if  the  first  time  */ 

If  #NOrES  > 0 then  go  to  S3. 

S2.1:  /*  First  time:  allocate  directory  */ 

Set  MX#DIRS  = 256;  /*  Majc.  no.  of  entries  */ 

Allocate  DIRCTRY 

S2.2:  /*  Initialize  First  directory  entry  (i.e.  root)  */ 

Set#  NODES  = 1; 

Set  #syinbol  = 1;  /*  No.  of  key  names  */ 

Set  keyname(l)  = NAMES ( 1) ; 

Set  keytype(l)  = TYPES(l) ; 

Set  Ref_list  = Null; 

Set  tree-link  = nil; 

Set  Cross-link  = nil. 

4 

S2.3:  /*  Initialize  TYPEhead:  list  heads  of  all  types  V 

Set  Typehead  = 0; 

Set  Typhead(TYPES(l))  =1. 


S3: 


/*  Start  processing  each  key  */ 

For  i = 1 to  N#,  perform  steps  S4  to  S12. 

S4:  /*  Get  keyname  and  type  § initialize  */ 


Set  Kham  = NAMES(i) ; 

Set  Ktyp  = TYPES(i) ; 

Set  jn,  jt  = 1.  /*  start  at  root  */ 

S5:  If  Kham  = keyname (jn) , then  go  to  S8; 

else  if  Knam  < keyname(jn),  then  go  to  S7 
S6:  /*  IGiam  > keyname (j n) : i;q3  */ 

If  UpCjn)  = nil  then 

Set  Up(jn)  = #NODES  +1,  and  go  to  7.1; 

othervdse  set  jn  = l^(jn),  and  go  to  S5. 

S7T  /*  Kham  < keyname  (jn) : down  */ 

If  Down(jn)  = nil,  then 
set  Down(jn)  = #NODES  + 1; 
othervd.se  set  jn  = DovTi(jn)  and  go  to  S5. 
S7.1:  Set  jn  = #NODES  +1; 

S8:  /*  Kham  = keyname ( j n) : check  type  */ 

set  jt  = jn; 

While  (jt  f nil),  perform  steps  S8.1 
and  S8. 2. 

S8.1:  If  ktyp  = keytype(jt),  then  go  to  S12. 
S8.2:  Set  jt  = Nexttype  (jt). 
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S9:  /*  Add  new  directory  entry  */ 

Set  #NODES  = #NODES  + 1; 

If  #NODES  > MX#DIRS,  then 
• Call  Expandjiirectory; 

Set  jt  = (hiodes. 

SIO:  /*  Fill  directory  entry  and  i^date  links  */ 
Set  keyname  (jt)  = Kham; 

Set  keytype  (jt)  = Ktyp; 

Set  Nextname  (jt)  = Typehead  (ktype) 

, Set  Typehead  (ktype)  = jt. 

Sll:  If  jt  = jn  then  go  to  S12. 

Set  Nexttype(jt)  = Nexttype(jn) ; 

« 

Set  Nexttype(jn)  = jt 
S12:  /*  Fill  and  link  storage  entry  */ 

Set  Key(i)  = jt; 

Set  Next(i)  = Ref- list (j t) ; 

Set  Reflist(jt)  to  point  to  the  storage  entry. 


Return. 


entry  for  them  (step  SI).  If  the  routine  is  invoked 
for  the  first  time,  then  the  directory  is  allocated 
and  initialized  (steps  S2  to  S2.3).  Otherwise,  the 
algorithm  searches  the  directory  for  a match  of  a key 
name  (steps  S3  to  S7).  If  the  keyname  has  been  in  the 
directory,  then  the  algorithm  proceeds  to  search  for 
the  keytype  (steps  S8  and  S9).  If  either  the  keyname 
in  the  former  search  or  the  key  type  in  the  latter 
search  is  not  found,  then  the  key  has  not  been  entered 
in  the  directory,  hence  a new  entry  is  created  and 
filled  (steps  S9  and  Sll).  Finally,  the  newly  created 
storage  entry  is  put  on  top  of  the  "reference  list" 


of  the  key  (step  S12).  This  process  is  repeated  once 
for  each  key. 

5.4.4  The  RETRIEVE  Routines 

There  are  two  procedures  of  this  type:  RETREVS 
and  RETREVD.  The  former  is  used  for  retrieving  desired 
storage  entries;  the  latter  for  desired  directory 
entries  of  a given  key  type  or  key  name.  The  data 
structures  depicted  in  Section  5.4.2  are  used  in  these 
two  routines. 

The  RETREVS  (OPTION,  RPTRS , NR,  STMT_TYPE)  pro- 
cedure has  four  input  parameters  as  indicated  in  paren- 
thesis. In  addition,  it  uses  three  common  variables: 
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N//,  NAMES  and  TYPES.  The  procedure  finds  all  storage 
entries  in  which  a conjunction  of  N//  keys  (specified 
in  NAMES  and/or  TYPES)  appears,  and  optionally  checks 
other  data  associated  with  such  storage  entries.  In 
other  words,  RETREVS  retrieves  all  the  storage  entries 
with  keys  satisfying  the  conjunction  and  the  data  typ,e. 

The  pointers  to  the  retrieved  storage  entries  are 
returned  in  RPTRS , while  the  total  number  of  such  entries 
are  returned  in  NR,  Keys  in  conjunction  may  be  negated, 
except  the  first  one.  A negation  of  a key  is  indicated 
by  negating  its  corresponding  key  type.  For  example, 

if  ith  key  is  to  be  negated,  then  TYPES(i)  should  be  ^ ' 

negative.  Finally,  there  are  two  options  of  specifying 
the  keys:  by  directory  locations  (indices)  of  the 
keys  if  known,  or  by  key  names  and  types  explicitly. 

The  input  parameters  and  common  variables  are  summarized 
in  the  following. 

OPTION  is  a one-bit  flag  indicating  how  the  keys. 

If  OPTION  = 0,  then  the  keys  are  specified  by 
their  directory  locations  in  TYPES.  Otherwise, 
the  key  names  are  in  NAMES,  and  key  types  in  TYPES. 

RPTRS  is  an  array  of  pointers  to  the  storage 
entries  retrieved. 

1^2 

^ J 


A 


NR  contains  the  total  number  of  such  storage 
entries  . 


STMT_TYPE  gives  the  statement  type  in  the  other 
data  associated  with  the  storage  entries.  If  it 
is  zero,  then  no  check  of  data  type  is  made.  If 
positive,  then  the  data  type  of  each  retrieved 
storage  entry  must  be  STMT_TYPE.  Otherwise, 
STMT_TYPE  is  negative,  the  data  type  must  not  be 
STMT_TYPE. 

N if  contains  the  total  number  of  keys. 

NAMES  is  an  array  of  key  names,  each  is  a variable- 
length  string  of  up  to  12  characters.  It  is  not 
used  if  OPTION  ■«  0. 

TYPES  is  an  integer  array.  The  absolute  value  of 
TYPES(i)  denotes  the  key  type  of  the  ith  key,  if 
OPTION  = 1.  Otherwise,  it  denotes  the  directory 
location  of  the  ith  key.  If  TYPES(i)  is  negative, 
then  the  ith  key  is  negated  in  the  conjunction. 

To  illustrate  the  usage  of  the  RETREVS  procedure, 
the  following  is  an  example  of  retrieving  storage  entries 
satisfying  a conjunction  of  two  keys:  X of  type  CONJ#, 
and  Y of  type  STIM#  but  negated  (in  NOPAL  system,  it 
means  to  retrieve  all  conjunctions  named  X which  are  not 
in  the  stimulus  Y). 
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N#  - 2;  NAMES(1)-’X';  TYPES(l)  - CONJ#; 

NAMES(2)-' Y'  ; TYPES(2)  « - STIM// ; 

CALL  RETREVS(’1'B,  P,  N,  0); 
where  P would  contain  a list  of  pointer's  to  those 
retrieved  storage  entries,  and  N would  be  set  to  the 
number  of  such  entries.  Suppose  the  directory  locations 
of  these  two  keys  have  already  been  known  as,  say,  K1 
and  K2,  then  the  following  calling  sequence  is  equivalent 
to  the  one  shown  above: 

N//  - 2;  TYPES(l)  » Kl;  TYPES(2)  - -K2  ; 

CALL  RETREVS  ('O'B,  P,  N,  0); 

Algorithm  5.2  shows  the  steps  of  RETREVS.  If 
option  1 is  used,  then  key  names  and  types  are  expli- 
citly specified  and  they  are  converted  to  the  corres- 
ponding directory  locations  by  searching  the  directory 
(steps  S2  to  S2.2).  The  algorithm,  then  proceeds  to 
search  each  storage  entry  containing  the  first  (i.e. 
leading)  key  (steps  S4-S5).  If  the  data  type  associated 
with  the  storage  entry  does  not  match  the  desired  state- 
ment type  (STMT_TYPE),  then  the  entry  is  skipped  (steps 

56- S6.3).  If  there  are  other  keys  in  conjunction,  then 
each  of  them  must  (or  must  not)  be  contained  in  the 
storage  entry  if  it  is  non-negated  (or  negated)  (steps 

57- S7.5).  If  the  storage  entry  turns  out  to  be  the 
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ALGORi™  5.2  RETREVS:  RETRIEVE  STORAGE  ENTRIES 
/*  There  are  four  parameters: 

Option  = a one-bit  flag  indicating  how  the  keys  are  provided  for 
I'etrieval , 

I^trs  = an  array  of  pointers  of  the  retrieval  storage  entries; 

Nr  = number  such  retrieved  entries; 

Stmt- type  = statement  type  as  additional  condition  for  retrieval. 
Also,  the  following  3 external  variables  are  used: 

N#  = number  keys  specified  for  this  retrieval; 

Names  = an  array  of  key  names,  if  option  = 1; 

Types  = an  array  of  key  types,  if  option  = 1; 

or  of  directory  locations  of  the  keys,  if  option  = 0.  */ 

SI:  If  option  =-0,  then  go  to  S3. 

S2;  /*  Key  names  and  types  are  explicitly  specified  */ 

Fbr  i = 1 to  N#,  perform  steps  S2.1  to  S2.2. 

S2.1;  Search  the  directory  for  the  key  denoted  by  Names  (i) 
and  Types  (i) ; 

Let  j be  the  location  of  the  directory  entry. 

S2.2:  Set  Types  (i)  = j. 

S3:  /*  Keys  are  specified  by  their  locations  (Types(*))  in  the 

directory  */ 

Set  key#l  = Types (1) ; 

Set  Nr  = 0; 

Set  Stoptr  = Reflist  (key#l) . 

S4:  /*  Trace  each  storage  entry  containing  first  key  */ 

IVhile  (stoptr  nidi),  perform  steps  S5  to  S9. 
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S5:  Let  k be  the  position  of  the  key  in  the  current  storage  entry. 

S6:  /*  check  statement  type  */ 

Let  Data-type  be  the  statement  type  stored  in  the  "other  data"; 
S6:l:  If  Stmt-type  = 0 or  Stmt  type  = Data  type,  then  go  to  S7. 
S6.2:  If  stmt  type  > 0 and  Data  type  f stmt  type,  then  go  to  S9. 

S6.3:  If  stmt  type  < 0 and  Data  type  = Stmt  type,  then  go  to  S9. 

S7:  /*  Check  other  keys  in  conjunction,  if  any  */ 

For  i = 2 to  N#,  perform  steps  S7.1  to  S7.5. 

S7.1:  Set  Key  # = Types (i);  /*  ith  key  */ 

S7.2:  If  Key  # < 0,  then  go  to  S7.4. 

S7.3;  /*  Key  # > 0:  in  conjunction  */ 

If  Key  # is  not  in  the  current  storage  entry,  then  go  to  S9; 
else  go  to  S7.5. 

S7.4:  /*  Key  # < 0:  not  in  conjunction  */ 

Set  Key  # = = Key  #; 

If  Key  # is  in  the  storage  entry,  then  go  to  S9. 

S7.5:  /*  End  of  looping  i */ 

S8:  /*  OK,  the  entry  should  be  retrieved  */ 

Set  Nr  = Nr  +1; 

Set  RPTRS(Nr)  = Stoptr; 

S9:  /*  Get  next  storage  entry  */ 

Set  Stoptr  = Next (k) , 

SIO:  Return. 
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desired  one,  then  its  pointer  is  saved  (step  S8). 
Finally,  the  algorithm  obtains  the  next  storage  entry 
in  the  "reference"  list  of  the  first  key  (step  S9), 
and  the  process  is  repeated. 

The  other  procedure  RETREVD  (OPTION,  RNODES , NR) 
has  three  input  parameters  and  two  common  variables 
NAMES  and  TYPES.  If  the  one-bit  OPTION  is  0,  then  it 
retrieves  all  directory  entries  which  contain  the  key 
type  specified  by  TYPES(l).  Otherwise,  the  algorithm 
retrieves  all  directory  entries  containing  the  keyname 
specified  by  NAMES(l).  The  locations  of  the  retrieved 
directory  entries  are  returned  in  RNDOES  , and  the  total 
number  in  NR.  Note  that  each  key  corresponds  to  one 
directory  entry,  as  indicated  by  the  structure  of  the 
directory  (Section  5.4.2).  For  example,  the  following 
sequence  of  PL/I  code  retrieves  all  directory  entries 
of  key  type  TEST//  (in  NOPAL  system,  it  is  equivalent 
to  obtaining  the  directory  locations  of  all  test  module 
names ) : 

* 

TYPES(l)  - TEST//;  CALL  RETREVD  (' 0 ' B , R,N); 
where  R would  contain  those  directory  locations,  and  N 
would  contain  the  total  number  of  them. 

Algorithm  5.3  outlines  the  steps  of  the  procedure 
RETREVD.  If  option  0 is  used,  then  the  key  type  is 
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ALGORITHM  5.3  RETREVD:  RETRIEVE  DIRECTORY  ENTRIES 


/*  There  are  three  parameters; 

Option  = a one-bit  flag  indicating  mode  of 
retrieval , 

\ 

Rnodes  = an  array  of  directory  entries  retrieved; 
Nr  = number  of  such  entries. 

In  addition,  the  following  two  external  variables 
are  used: 


Names  = an 

array  of 

key  name. 

if  option  = 1; 

Types  = an 

array  of 

key  types 

, if  option  = 0 */ 

S 1 : 

If 

option  = 1, 

then  go  to  S5. 

S2  : 

/* 

Option  = 0; 

retrieves 

all  div. 

entries  with  same  type 

*/ 

4 

/* 

Get  the  keytype  from 

types ( 1 ) 

*/ 

Sat  type  = Types  (1 ) ; 

Sat  X = Typehead  (typel . 

33:  While  k # nil,  perform  steps  3.1  to  3.2. 

3:.l.  Sat  Nr  ^ i-  1. 

Set  Rnodes(Nr)  = k 
S3. 2:  Set  k = Nextname  (k)  . 

3.^:  Go  to  S8 

j5;  /*  Option  = 1,  retrieve  all  dir.  entries  with  same 

name  */ 

/*  Get  the  key  name  from  Names (1)  */ 

Set  kname  = Names  (1); 


*2  • ♦- 


I 


S6;  /*  Search  key  name  */ 

While  k ^ nil,  perform  step  S6.1, 

S6.1:  If  kname  > Keyname(k)  then 

set  kn  = Up (k) ; 

else  if  kname  <Keyname(k)  then 
set  kn  = Down(k); 
else  go  to  S7.  /*  name  found  */ 

S7:  /*  Get  all  entries  with  the  same  name  */ 

While  k = nil,  perform  steps  S7.1  to  S7.2. 
S7.1:  Set  Nr  = Nr  + 1 ; 

Set  Rnodes  (Nr)  = k. 

S7.2:  Set  k = Nexttype  (k)  . 

S8:  Return. 
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given  in  TYPES(l)  and  the  algorithm  gets  all  the 

^ directory  entries  with  the  same  key  type  via  a link  j 

field,  NEXTNAME (steps  S2-S4).  Otherwise,  the  key  name 
[■  { 

h is  specified  in  NAMES(l),  and  the  directory  is  searched  I 

I for  the  first  entry  containing  the  key  name  (steps  j 

r 

[ S5-S6.1).  Then  the  algorithm  obtains  all  the  directory 

^ entries  containing  the  same  key  name  via  another  link  ! 

I field,  NEXTTYPE  (steps  S7-S7.2).  ‘ 

I : 

I 5.5  NOPAL  SPECIFICATION  REPORTS  ! 

There  are  two  NOPAL  specification  reports  which 
are  available  to  the  user  at  his  discretion.  The  Source 
specification  report  is  a by-product  of  the  syntax 
analysis  phase.  The  reformatted  specification  report 
is  produced  from  the  stored  NOPAL  statements  in  the 
I simulated  associative  memory.  These  two  reports  are 

r 

I briefly  discussed  in  the  next  sub-sections  respectively. 

5.5.1  Source  Specification  and  Syntax  Error  Reports 
The  source  specification  report  is  the  image  of 
the  NOPAL  specification  provided  by  the  user,  except 
that  each  statement  is  prefixed  by  a corresponding  state- 
ment number  generated  by  the  Processor.  These  state- 
ment numbers  are  referenced  in  the  syntax  error  report, 
the  cross-reference-attribute  report,  and  the  cross- 


reference  error  report  (the  last  two  reports  are 
discussed  in  Section  5.6).  Therefore  this  report  is 
useful  to  the  user  during  the  debugging  stage.  As  shown 
in  Figure  5.3,  the  report  is  generated  by  the  lexical 
analyzer  (LEX)  as  a by-product.  This  report  may 
optionally  be  suppressed  by  giving  a run-time  parameter 
(NOSAPLIST).  A sample  source  specification  report  is 
given  in  Figure  3.2. 

The  Syntax  error  report  is  another  document  which 
lists  all  syntax  error  or  warning  messages  detected  by 
the  Processor  during  the  syntax  analysis  phase.  As 
indicated  in  Figure  5.3  this  report  is  generated  by  a 
collection  of  error  message  routines  (see  Section  5.3.2). 
If  an  error  is  encountered  in  a statement,  then  the 
corresponding  error  code  and  statement  number  will 
appear  in  this  report.  The  error  codes  are  enumerated 
in  Table  5.4.  In  the  case  of  warning  messages,  they  are 
usually  informatory. 

5.5.2  Reformatted  Specification  Report 

A specification  report,  reformatted  and  reorganized 
for  better  readability,  is  produced  by  a program  module 
(S0URCE2)  whose  input  is  the  whole  collection  of  NOPAL 
statements  stored  in  the  simulated  associative  memory. 
Basically  this  reformatted  specification  report  lists 
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the  three  major  sections  (test-modules,  UUT , and  ATE) 
of  the  NOPAL  specification  in  that  order,  with  proper 
headings  and  indentation.  All  default  information  is 
provided  in  this  report.  Thus,  this  is  a complete, 
purely  non-procedural  NOPAL  specification  and  is 
acceptable  to  the  NOPAL  Processor.  This  report  is  use- 
ful to  the  user,  particularly  when  his  source  specifi- 
cation is  not  well-organized. 

The  S0URCE2  routine  produces  the  reformatted 
specification  report  by  traversing  the  directory  and 
storage  entries  using  RETRIEVE  subsystem.  This  report, 
can  be  suppressed  by  giving  a run-time  parameter 
(N0S0URCE2) . 

Figure  5.7  shows  a portion  of  a typical  reformatted 
specification  report. 

5.6  Cross  Reference  Reports 

This  section  presents  the  subsystem  which  produces 
a sec  of  siz  cross  reference  reports  as  summarized  in 
lable  5.1.  As  indicated  in  Figure  5.3,  these  reports 
are  generated  by  a program  module  XREF  ( in  fact, 

XRFFl  and  XREF2)  whose  input  is  the  stored  NOPAL 
specification.  Section  5.6.1  describes  the  cross- 
reference  and  attribute  report’  produced  by  XREFl. 
Section  5.6.2  presents  the  other  cross-reference 
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/*  reformatted  specification  report,  file:  sources  */ 


/*■ 


* i it-ii  J«  .-,1  1 


/*  NOPAL  TEST  SPECIFICATION  FOR  MINIRAOIOSET 


»/ 


/*■ 


1'/ 


NOPAL  SPECIFICATION  MINIRADIOSET; 


/* 

/*  TEST 

modules : 

*/ 

6 */ 

/* 

/■m  » -M*  *-*»  1 

saliTftBSiac  9 "MM  M'm 

TEST  DC.INPUT; 


/♦  NULL  STIMULI 


MEASUREHENr  iM_OC_  INPUT  i DC_  INPUT  ) ; 


CONJUNCTION  SM_W0001(  SM_OC_  INPUT  ) : 

(<J2A_B,  J24_C>  = CONST_R(MR£S  OHM  )) 

TARGET:  MRES; 


ASSERT  ION  $M_W0002 ( $M_DC_ I NPU T J : 

MRES  > 100 

SOURCE  : MRES  ; 


LOGIC  SLUGICOOICI  DC..INPUT  ) : |-.02,  «D3; 


DIAGNOSIS  02: 

operator  MESSAGE: 

AFFECTED  COMPONENT S= IN  PUT. SHC RT , 
TY?E  = i!<^; 


DIAGNOSIS  03: 

OPERATOR  MESSAGE: 

OTHER  PAPAMETERS= (MRES , ' OHMS'), 

type=0; 


FIGURE  5.7  EXAMPLE  OF  REFORMATTED  SPECIFICATION  REPORT 
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reports  generated  by  XREF2 . 

5.6.1  Cross  Reference  and  Attribute  Report  (XREF- 
ATTR) 

The  XREF-ATTR  report  is  a useful  product  of  the 
syntax  and  statement  analysis  phase.  It  is  produced 
by  a cross-reference  routine  (XREFl)  by  inputting  the 
NOPAL  statements  stored  in  the  simulated  associative 
memory.  This  report  provides  an  alphabetical  listing 
of  all  the  names  (as  identifiers  or  labels)  defined 
by  the  user  in  the  submitted  NOPAL  specification.  For 
each  name,  the  XREF-ATTRt report  gives  the  statement 
number  of  the  statement  which  defines  the  entity,  the 
statement  numbers  of  the  statements  which  reference 
the  name,  and  a list  of  attributes  regarding  the  name. 
Thus,  this  report  is  useful  to  the  user  during  the 
debugging  stage. 

Figure  5.8  shows  an  example  of  a typical  XREF-ATTR 
report. 

The  printing  of  this  report  can  be  suppressed  by 
giving  a run-time  parameter  (NQXREFl) . 

The  XREFl  routine  produces  this  report  by  traversing 
the  directory  and  by  invoking  the  RETRIEVE  routine  to 
obtain  the  corresponding  references.  Since  the  directory 
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CROSS  REFERENCE  AND  ATTRIBUTES  REPORT 


NAME  DcF  NO.  attributes  AND  P.EPEREHCES 


<15 

56 

MESSAGE  label 

<17 

57 

31 

MESSAGE  LABEL 

«ia 

58 

33 

MESSAGE  LABEL 

53 

22  51 

MESSAGE  LABEL 

*5 

54 

7 

MESSAGE  LABEL 

»6 

55 

41 

MESSAGE  LABEL 

AMPL 

S 

14  42 

TEST  LA6EL 

AMPL_TOL 

78 

10  12 

ate-runction  id,  P 

ATE_J24e 

81 

14  68 

ATE-POTNT  ID 

4UCI0_10NW 

69 

COMPONENT  10,  nitm  failure-punction:  rer.volt 
33 

AUC10_10MW 

70 

COMPONENT  10,  with  failure-function:  DISTORT 

5 1 

AUOIO_2W 

71 

COMPONENT  ID,  WITH  FAILURE-FUNCTICAl:  DISTORT 

22 

A 1 

A2 

28 

29 

ASSERTION  LABEL 

ASSERTION  label 

CONST_R 

73 

Aie-rU^CT  10^^  ro»  M 

4 

comst_s 

72 

ATE-FUMCTIDN  ID,  S 

36  25  1 7 45 

0 

52 

MESSAGE  LABEL 

8 13  32  43  50 

OC_INPUT 

2 

TEST  LABEL 

3 6 

5cv 

35 

STIMULUS  LABEL 

36  25 

DCV_AMS 

24 

STIMULUS  LABEL 

25  17  45 

oislpay 

DISTORT 

52 

30 

SYNONYM  Cf  MESSAf^E  LABEL:  0 

ATE-FUNCTION  10,  F 

01STORT_VOlT 

23 

22  51  70  71 

TEST  LABEL 

DIST0PT_1CNW 

24  26  30 

TEST  LABEL 

DISTORT_rw 

15 

4?  46  49 

TEST  LABEL 

01 STORTION 

75 

16  18  21 

ATE-FUNCTION  10,  M 

02 

7 

n 41 

oiagnosis  label 

03 

3 

5 

OIAGNOSIS  label 

04 

5 

OIAGNOSIS  LABEL 

05 

42 

zrjs 

DIAGNOSIS  LASEL 

NC 

PICDRE  5.8 

EXAMPLE  OF  XREF-ATTR  REPORT 
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is  itself  a binary-tree  structure,  an  alphabetic  ordering 
of  names  is  easily  achieved  by  an  in-order  traversal 
of  the  directory  (i.e.,  left  subtree  first,  then  the 
node,  finally  the  right  subtree). 

Any  errors  or  warnings  which  are  detected  during 
this  phase  of  cross-referencing  are  displayed  in  a 
separate  XREFl  error  report. 

During  the  process  of  generating  this  report, 
three  other  minor  tasks  are  also  accomplished.  First, 
all  the  s t imulus /measur emen t waveform  conjunction 
back  references  are  resolved  before  the  production  of 
the  XREF-ATTR  report  is  actually  begun.  Second,  for 
each  variable,  its  scope  (global  or  local)  is  determined. 
Furthermore,  an  occurrence  of  a variable  in  a conjunction 
or  an  assertion  is  considered  as  SOURCE  by  default, 
hence  it  is  put  in  the  corresponding  source-variable 
list  unless  it  is  otherwise  declared  as  TARGET.  The 
detailed  stepj  are  provided  in  Algorithm  6.1  of  Chapter 
6.  Last,  to  facilitate  later  phases  of  processing,  the 
stimulus,  measurement,  and  logic-diagnosis  list  of  each 
test  module  are  explicitly  linked  to  the  test  module. 
Similarly,  the  conjunction  and  assertions  are  explicitly 
linked  to  their  corresponding  parent  stimuli  or 


measurement . 


5.6.2  Other  Cross  Reference  Reports:  DIAG-TEST, 

MESS-DIAG-TEST , COMP-DIAG-TEST , UUT . PT-TEST -AT E . 

PT  and  FUNC-TEST 

Available  to  the  user  are  five  additional  cross- 
reference  reports  which  are  generated  from  the  stored 
NOPAL  statements  by  a program  module  (XREF2).  Basically, 
they  are  reports  in  which  the  test  modules  are  cross- 
referenced  with  the  diagnosis,  the  messages,  the 
affected  components,  the  UUT  and  ATE  connecting  points, 
or  the  ATE  functions  (as  enumerated  in  Table  5.1). 

These  reports  provide  better  man-machine  interface  and 
give  the  user  a clear  picture  of  interactions  among 
various  components  of  his  test  specification.  They 
may  be  entirely  suppressed  by  giving  a run-time 
parameter  (N0XREF2) . 

In  the  DIAG-TEST  report  diagnoses  are  cross- 
referenced  with  the  test  modules.  For  each  diagnosis, 
this  report  lists  the  names  of  the  test  modules  which 
ever  references  the  diagnosis. 

The  MESS-DIAG-TEST  report  provides  a listing  of 
all  the  message  names,  together  with  the  corresponding 
diagnoses  and  test  modules  which  refer  to  them. 

The  COMP-DIAG-TEST  report  lists  all  the  affected 
components  ( i . e .,  component  failures),  with  all  the 
referencing  diagnoses  and  test  modules. 
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The  UUT. PT-TEST-ATE. PT  report  lists  all  the  UUT 


A 


connecting  points.  For  each  UUT  connecting  point, 
the  report  provides  ail  the  test  modules  referencing 
it,  with  the  stimulus  or  measurement  sections  pro- 
perly suffixed.  Also  provided  in  the  report  is  a 
list  of  ATE  interconnecting  points  which  are  connected 
directly,  or  indirectly  through  ATE-UUT  interface,  with 
the  given  UUT  connecting  point. 

The  last  cross  reference  report,  FUNC-TEST  report 
provides  a list  of  ATE  functions.  For  each  function, 
the  report  lists  all  of  its  referencing  test  modules, 
with  stimuli  or  measurements  properly  suffixed. 

Figure  5.9  through  5.11  show  an  example  of  these 
five  cross-reference  reports. 

These  cross-reference  reports  should  be  useful  to 
the  user  as  a debugging  aid  or  for  the  purpose  of  better 
understanding  his  own  NOPAL  test  specification. 


Figure  5.9  Example  of  Diag-Test  Report 
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CHAPTER  6 


SPECIFICATION  ANALYSIS  AND  SEQUENCE  DETERMINATION 

I 

6.1  INTRODUCTION  AND  BACKGROUND: 

This  phase  of  the  NOPAL  processor  deals  with  the 
analysis  of  NOPAL  specification,  automatic  program 
design,  and  determination  of  sequence  based  on  an 
application  of  graph  theory.  The  analysis  of  infor- 
mation relationships  and  automatic  sequencing  by  means 
of  graphs  have  been  successfully  used  in  the  recent 
MODEL  system  [RIN  76].  This  section  presents  the 
background  and  terminology  involved  in  this  phase. 

It  also  describes  the  graphs,  matrices,  and  other  data 
structures  that  are  generated  from  a NOPAL  specifi- 
cation. 

In  order  to  explain  the  algorithms  and  data 
structures  used,  the  sample  NOPAL  specification  MINI- 
RADIOSET, presented  in  Figure  3.2  will  be  frequently 
referred  to  in  the  subsequent  discussions. 

In  a NOPAL  specification,  each  entity  (e.g.  test, 
diagnosis,  conjunction,  assertion,  and  variable)  is 
given  a symbolic  name  which  is  either  provided  by  the 
user  or  generated  by  the  Processor.  In  this  phase  each 
name  is  related  to  others  in  one  of  the  several  ways. 


For  example,  a data  determlnacy  relationship  exists 
between  a test  module  having  a global  TARGET  variable 
and  the  variable,  also  between  a global  variable  and  a 
test  module  referring  to  the  variable  as  SOURCE. 

In  all  these  relationships,  referred  to  as  pre- 
cedence relationships,  the  former  in  a sense  must  pre- 
cede the  latter  at  execution  time  of  the  object  test 
program  and  is  said  to  be  a predecessor  of  the  latter, 
while  the  latter  is  said  to  be  a successor  of  the 
former.  All  types  of  precedence  relationships  that 
exist  among  test  modules  are  summarized  in  Table  6.1. 

As  for  the  precedence  relationships  internal  to  a given 
test  module,  there  are  merely  two  types,  data  deter- 
minacy  and  waveform  setup.  These  are  further  explained 
later.  The  types  of  precedence  relationships  dictate 
the  following:  1)  how  the  conjunction  and  assertions 

are  analyzed  and  sequenced  internally,  2)  how  the  test 
modules  are  analyzed  and  sequenced  externally,  and  3)  how 
the  object  program  is  generated.  For  instance,  a global 
variable  must  be  evaluated  first  in  the  predecessor  test 
module  before  the  variable  can  be  used  in  another  suc- 
cessor test  module.  Such  precedence  information  is  con- 
veyed in  a "directed  graph",  as  described  below,  one  for 
the  entire  aggregate  of  test  modules  and  one  for  each 
test  module . 


21  3 


INTER-'  T'  MOOULF,  PRECEnFNCE  RELATIONSHIPS 
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TABLE  6.1  (continued) 
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Formally,  a directed  graph  [AHO  74,  DEO  74]  (or  a 


digraph^  G ■ < N,  E > consists  of  a finite,  non-empty 

< 

set  of  nodes  (or  vertices)  N and  a set  of  edges  (or 
arcs)  E where  each  edge  is  an  ordered  pair  (c,h)  of 
nodes;  t is  called  the  tail  and  h the  head  of  the  edge 
(t,h).  Node  h is  said  to  be  ad  1 acent  to  node  t,  while 
edge  (t,h)  is  said  to  be  f rom  t ^ h. 

A weighted  directed  graph  is  a directed  graph  in 
which  each  edge  (t,h)  from  node  t to  node  h is  asso- 
ciated with  one  of  a set  of  types  of  relationships. 

Weighted  directed  graphs  are  used  to  represent  all 
the  different  types  of  precedence  relationships  derived 
from  the  NOPAL  statements.  As  an  example,  the  weighted 
digraph  shown  in  Figure  6.1  corresponds  to  the  inter- 
test-module relationships  of  the  example  of  Figure  3.2. 
In  this  graph  each  node  represents  the  name  of  one  of 
the  entities  in  the  NOPAL  specifications:  test  modules, 
diagnoses,  and  (global)  variables.  Note  that  each  node 
may  have  0,  1,  or  more  edges  emanating  from  it  to 

successor  nodes. 

Although  a pictorial  representation  of  a graph  is 
very  convenient  for  visual  study,  there  are  other  repre- 
sentations which  are  better  for  computer  processing  [DEO 
74].  One  such  representation  called  ad  1 acency  matrix  is 
used  in  the  analysis  phase  of  the  NOPAL  processor. 
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LEGEND : 


Test  module  node 

Data  node 


Diagnosis  node 

Edge  of  precedence  type  n 


Figure  6.1  Digraph  for  NOPAL  Specification  MINIRADIOSET 


Given  a digrpah  G - < N,  E > consisting  of  a set 

of  n nodes  N “ { V^i  •••.  } and  a set  of  edges 

E,  an  adjacency  matrix.  A,  corresponding  to  the  digraph 
G is  an  n X n matrix  such  that  for  all  i and  j ( 1 <“  i, 

j <»  n) 

A(i,j)  « 1 if  (V^,  V^)  is  an  edge  in  E; 

“ 0 o therwise . 

A weighted  adiacency  matrix  which  corresponds  to 
the  weighted  digraph  is  used  in  order  to  differentiate 
the  various  types  of  relationships  that  may  exist  between 
two  nodes  of  the  digraph.  This  matrix  is  the  same  as 
the  adjacency  matrix  A except  that  it  has  a positive 
number  indicating  a certain  type  of  relationship  when- 
ever the  corresponding  entry  in  A has  a value  of  1. 

Formally,  a weighted  adjacency  matrix  correspond- 
ing to  the  digraph  G is  an  n x n matrix  W such  that  for 
each  i and  j with  1 <«i,  j <»n 

W(i,j)  ■ k if  (V^,  Vj ) is  an  edge  of  type  k in  E, 
n a m o 1 y ^ 

(V^,  Vj ) is  in  raxaeion  of  type  k ; 

■ 0 otherwise. 

The  weighted  adjacency  matrix  for  a NOPAL  specifi- 
ccxicn  is  used  extensively  in  the  phases  of  analysis, 
sequencing,  and  code  generation.  Such  a matrix  corres- 
ponding to  the  MINIRADIOSET  example  of  Figure  3.2  (hence 
the  digraph  of  Figure  6.1)  is  shown  in  Figure  6.2.  The  node 
■ uipoer?  tc  the  Iff  of  i. ode  nairtt  a^e  assigned  by  the 
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Processor.  Kntries  (i,j)  in  the  matrix  are  either  0,  indicating 
no  relationship  exists  between  the  node  1 (at  ith  row)  and  the 
node  j (at  j th  column),  or  a positive  number  corresponding  to  the 
type  of  precedence  relationship  between  node  1 and  node  j.  These 
type  numbers  correspond  to  the  precedence  types  listed  in 
Table  6.1.  To  further  Illustrate  the  precedence  relationships, 
those  precedence  types  and  relationships  which  are  extracted  from 
the  sample  specification  MINIRADIOSET  are  enumerated  in  Table  6.2. 

All  the  global  precedence  information  is  conveyed  by  a 
weighted  adjacency  matrix  for  the  whole  NOPAL  specification. 
Likewise,  all  the  local  precedence  information  in  each  test  mod- 
ule is  also  represented  by  a weighted  adjacency  matrix.  Such 
precedence  information  is  entered  into  the  matrices  and  analyzed 
in  subsequent  sections. 

As  illustrated  in  Figure  6.3,  there  are  two  major  subphases 
of  analysis  and  sequencing:  intra-tes  t-mod  ule  and  inter-tes  t- 
module . The  former  concentrates  internally  on  the  waveform  con- 
junctions, assertions,  and  diagnoses  of  a given  test  module. 

The  latter  focuses  externally  on  the  whole  collection  of  test 
modules  in  a given  NOPAL  specification,  considering  each  test 
module  as  an  integral  unit. 

Section  6.2  gives  an  overview  of  the  subphases  common  to 
both  the  intra-  and  inter-test  module  analysis  and  sequencing. 
Section  6.3  presents  in  detail  all  the  subphases  of  intra-test- 
module  analysis  and  sequence  determination.  Section  6.4 
discusses  various  subphases  of  in te r- te s t-mod ul e analysis  and 
sequencing. 
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FIGURE  6.2  WEIGHTED  ADJACENCY  MATRIX  FOR  NOPAL  SPECIFICATION  OF  MINIRADIOSET 


TABLE  6.2  ILLUSTRATION  OF  PRECEDENCE  RELATIONSHIPS  FOR  MATRIX  OF  FIGURE  6.2 


FIGURE  6.3  FLOWCHART  FOR  PHASES  II  AND  III  OF 

NCr\L  PROC".:^f'’^ 
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6.2  OVERVIEW  OF  SUBPHASES  IN  GRAPH  ANALYSIS  AND 

SEQUENCING 

A weighted  digraph  of  the  NOPAL  specification  as 
represented  by  a weighted  adjacency  matrix  is  a vehicle 
used  by  the  NOPAL  Processor  to  sequence  operations  and 
to  detect  errors  in  the  specification. 

Before  and  during  the  process  of  gathering  and 
entering  precedence  relationships  in  the  weighted 
adjacency  matrix,  some  logic  errors  in  the  specification 
may  be  detected,  and  appropriate  messages  sent  to  the 
user.  Further  error  analysis  occurs  after  the  matrix 
has  been  constructed.  Table  6.3  summarizes  the  error/ 
warning  messages  which  can  possibly  be  produced  by  the 
Processor  during  the  phase  of  graph  creation  and  analysis 
(after  the  syntax  analysis  phase).  The  reference  numbers 
in  the  first  column  will  be  referred  to  occ as s ional ly 
during  the  subsequent  discussions. 

Variables  that  are  global  (or  local)  to  a test  module 
are  involved  in  determining  one  type  of  precedence  relat- 
ion (data  determinacy)  in  the  phase  of  in  ter- 1 es t -modu le 
(or  intra-test-module)  analysis  and  sequencing.  There- 
fore, the  scope  (global  or  local  to  a test  module)  of 
each  variable  in  the  whole  NOPAL  specification  must  be 
determined  before  the  actual  analysis  and  sequencing  of 
test  modules  begin  (internally  and  externally). 
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Basically  if  a variable  X has  ever  been  defined  as 
TARGET  alone,  or  used  as  SOURCE  alone  in  any  test  module 
of  the  NOPAL  specification,  then  X is  considered  as  a 
global  variable  (i.e.,  of  scope  global).  Otherwise,  X 
is  local  (i.e.,  of  scope  local)  to  each  respective  test 
module  where  it  has  been  both  defined  as  TARGET  and  used 
as  SOURCE.  Algorithm  6.1  determines  the  scope  (local 
or  global)  of  every  variable  in  the  NOPAL  specification. 

It  also  designates  as  SOURCE  every  variable  which  has 
never  been  explicitly  declared  as  TARGET  or  SOURCE  by 
the  user.  This  relieves  the  user  of  the  burden  of  de- 
claring SOURCE  variables  explicitly.  For  the  sake  of 
efficiency,  this  algorithm  is  imbedded  in  the  XREFl 
routine  (for  cross-reference  and  attributes  in  Chapter  5) 
in  current  implementation. 

Table  6.4  summarizes  the  steps  involved  in  the 
creation  and  analysis  of  the  weighted  adjacency  matrix 
representation  of  a digraph  and  in  the  determination  of 
sequence,  commonly  applicable  to  both  the  internal  and 
external  analysis  and  sequencing  of  test  modules.  Detail- 
ed sub-phases  in  intra-test-module  and  inter-test-module 
analysis  and  sequencing  are  presented  in  Sections  6.3 
and  6 . 4,  respectively. 
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TABLE  6.3 


ERROR/WARNING  MESSAGES  ( XREF / ANALYS I S ) 


Ref# 


Message 


I ssued  by 


Brief  explana- 
tion/ Examp le 


TABLE  6.3 


ERROR/WARNING  ME S S AGE S ( XREF / ANALY S I S ) (CONTINUED) 


Ref//  Message 


Issued  by:  Brief  explana- 

t ion/ Examp le 


6 ERROR  (ambiguity):  INTSEQ 

TARGET  variable  x 
in  assertion  y of 
test  z is  no t the 
only  expression  at 
the  left-hand  side 
of  the  equal  sign 
("  = ") 

7 WARNING  (Inconsistency):  INTSEQ 

In  assertion  x of  test 
y,  a variable  is  de- 
clared as  target , 
but  the  relation 
operator  is  not  an 
equal  sign  ("•"  ) . 

Replaced  by  an  equal 
sign. 

R WARNING  (possible  EXTSEQ 

incompleteness) : 

Test  module  X does 
not  have  any 
diagnos is 


9 WARNING  rpossible  EXTSEQ 

inconsistency)  : 

Both  interactive- 
ness and  component 
protection  relation- 
ships exist  between 
diagnosis  d and  test 
module  t;  only  the 
interactiveness 
relationship  is 
retained 


10  ERROR  (ambiguity):  EXTSEQ 

Two  logical  operators 
x,y  connect  test 
module  t with  diagnosis 

d . 


W - X + 1 

TARGET.:  X; 
or 

X - 1 - W 

TARGET:  X; 


V > W + 3 

TARGET:  V; 


A test  has 
null  logic- 
diag . list 


- ».b 


TABLE  6.3 


ERROR/WARNING  MES S AGES ( XRE F/ ANALYS I S ) (CONTINUED) 


Ref#  Message 


Issued  by;  Brief  explana- 

tion/ Example 


11  WARNING  (possible  XREFl 

amb iguity) : 

X is  defined/used 
as  a local  vari- 
able in  tests  . . . ; 
and  also  in 
diagnoses  . . . 

12  WARNING  (apparent  XREFl 

inconsistency)  : 

In  stmnt  xxxx,  X 
multiply  defined. 

The  stmnt  deleted. 


Local  variable  X 
used  in  two 
diagnoses  of  two 
different  tests. 


Multiple  state- 
ment definition 
e.g.  TEST  X: 

« 

Te’sT  X; 


13  WARNING  (possible  XREFl 

incompleteness) : 

In  Stmnt  xxxx. 

Diagnosis  X 
never  referenced. 

14  ERROR  (incon-  XREFl 

sistency) : 

In  stmnt  a , b , c , . . . 
conjunction  back 
references  form 
a loop. 

15  ERROR  (incon-  EXTSEQ 

sis  tency) ; 

, Two  or  more 

tests:  . . . come 
after  the  diagnosis 
d via  logical 
operator  after 
(' A'  ) 

or  after-not 
(’ A-,  ’ ) 


Diagnosis  X was 
defined,  but  never 
used . 


Circular  stimuli 
conjunction  back 
references  . 
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ALGORITHM  6.1  DETERMINE  SCOPES  OF  VARIABLES  AND  IDENTIFY 
SOURCE  VARIABLES 

SO:  For  each  variable  X in  the  NOPAL  specification, 

perforin  steps  SI  through  S44. 

SI:  Get  all  //SE  storage  entries  of  X; 

Set  #DEF,  #REF,  ND  - 0. 

S2:  For  i - 1 to  #SE,  perform  steps  S3  to  SIO. 

S3:  Set  DEF(i),  DONE(i)  - 0;  /*  false  */ 

S4:  If  ith  statement  type  is  not  diagnosis 

then  go  to  S7  : 

S5 : /*  Setup  "used"  list  of  referencing  logic 

entries . 

Not  relevant  here  */ 

S6:  If  X is  not  an  operator  response  variable, 

then  go  to  SIO;  else  go  to  S9. 

S7:  /*  Set  up  test-label  field  of  conjunction 

or  assertion.  Not  relevant  here  */ 

S8:  If  X is  not  a TARGET  variable,  then  go  to 

SIO. 

S9:  /*  accumulate  definition  entries  */ 

Set  #DEF  - #DEF  +1; 

Set  DEF(i),  DONE(i)  - 1;  /*  true  */ 


/*  Set  TVAL2  (//DEF)  ■ # of  dimensions  of 
X */ 


S12;  Get  ith  definition  entry  (via  TVAL  (i)); 

/*  If  TVAL2(i)  ? 0,  then  X an  array  */ 

S13:  If  current  STMT. TYPE  is  not  a diagnosis 

then  go  to  S16 . 

S14:  Set  N “ # of  LOGIC  entries  referencing  the 

diagnosis  ; 

Set  TEST_IDS  (j)  = the  test  label  of  jth 
LOGIC  entry,  for  j » 1 to  N; 

Go  to  S 17  ; 

S15  : Set  N -=  1 ; 

Set  TEST_1DS(1)  = the  test  label  of  the 
wave  f o rm ; 

S17;  For  k •>  1 to  N,  perform  steps  S18  to  S26. 

S18;.  Set  TEST_ID  = TEST_TDS(k). 

S19:  For  j = 1 to  #SE,  performs  steps  S20 

to  S26. 

S20:  If  current  (via  jth  storage  entry) 

statement  type  is  not  diagnosis, 
then  go  to  S23 . 

S21:  If  DEF(j)  - 1 and  X is  not  in  the  other 

parameters  of  the  diagnosis,  then  go  to 
S26. 

S22:  Search  all  LOGIC  entries  referencing 

the  diagnosis;  If  there  exists  a LOGIC 
entry  in  the  test  module  with  label  = 
TEST_ID,  then  go  to  S25;  else  go  to  S26. 
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S2j:  If  DEF(j)  - 1,  then  go  to  S26;  if  X is 

not  in  the  SOURCE  variable  list,  then 
add  X to  the  list. 

S24:  If  the  waveform  is  not  in  the  module  with 

label  = TEST_ID,  then  go  to  S26. 

S25:  /*  accumulate  local  references  */ 

Set  //REF  = //REF  +1; 

Set  REFERENCE  (//REF)  = j; 

Set  DONE(j)  = 1. 

S26:  /*  End  of  looping  j */ 

S27:  /*  Accumulate  definition  and  save  its  local 

references  */ 

Set  ND  = ND  +1; 

Set  DEFN  (ND)  = TVAL(i); 

Set  REEL  (ND)  = //REF; 

S28:  /*  end  of  looping  k from  S17  */ 

S29:  /*  end  of  looping  i from  Sll  */ 

S30:  /*  determine  scope  of  X;  global  or  local  */ 

Set  SCOPESW  = 0;  /*  0 = local;  1 = global  */ 

Set  K = 0. 

S31:  For  i = 1 to  //SE,  is  every  DONE  ( i ) = 1? 

If  yes,  then  go  to  S33. 

S32:  /*  some  residual  global  references,  so  X 

global  */ 

Set  SCOPESW  = 1; 

Add  each  entry  with  DONE(i)  = 0 to  the  stack 
REFERENCE,  and  mark  its  SCOPE  field  for  X as 
global ; go  to  S37 . 

S33:  For  i = 1 to  ND  while  (SCOPESW  = 1),  perform 

the  step  S34 . 

S34:  Set  j = REFL(i)  ; 
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If  k = j,  then  set  SCOPESW  = 1; 
else  set  k = j . 

S35:  If  SCOPESW  = 0,  then  go  to  S43. 

S36:  /*  get  all  reference  entries  */ 

S37:  For  1 = 1 to  ND,  perform  steps  S38  to  S41. 

S38:  If  i > 1 and  DEFN(i)  = DEFN(i  -1), 

then  go  to  S41  . 

S39:  Mark  the  SCOPE  field  for  X as  global 

S40:  /*  Output  XREF  and  ATR  entry  */ 

S41:  /*  end  of  looping  i from  S37  */ 

S42:  Go  to  S44 

S43:  /*  local  variable(s)  */ 

/*  For  i = 1 to  ND,  output  XREF  & ATTR 
entries  */ 

S44:  If  X has  been  used  in  two  test  modules 

or  more,  and  also  in  two  diagnoses  or 
more,  then  output  error  message  #11. 

S45:  /*  end  of  looping  from  SO  */ 

S46:  Return; 
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TABLE  6.4  STEPS  IN  DIGRAPH  CREATION  AND  ANALYSIS, 
AND  SEQUENCE  DETERMINATION 


STEP  NAME 

1.  Create  Weighted 

Adjacency  Matrix  W 


2 Enter  Precedence 
Relationships  (by 
type  numbers)  Into 
matrix  W 

3 Perform  Graph  Analysis 


4 Cycle  Detection  and 
Eliminat ion 


5 Sequence  Determination 


SUMMARY  OF  TASKS 

Determine  total  number 
(n)  of  nodes  in  digraph; 
assign  node  number  to 
each  entry;  create  nxn 
matrix  W (initialized 
tozeros) 

Search  every  precedence 
relationship  between  a 
predecessor  and  successor 
and  enter  its  type  to  W. 

Create  (unweighted)  adja- 
cency matrix  A from  W; 
analyze  W and/or  A to  en- 
sure that  no  error 
conditions  exist  (except 
possible  cycles) 

Create  path  matrix  from 
A;  search  for  possible 
cycles;  delete  the 
cycles  if  possible;  other- 
wise report  as  error  to 
user . 

Rank  the  nodes  of  the  di- 
graph according  to  pre- 
cedence, and  then  reorder 
the  nodes  by  their  rank. 
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6.3  INTRA-TEST-MODULE  ANALYSIS  AND  SEQUENCING 

This  section  presents  in  greater  detail  the  sub- 
phases of  intra-test-module  graph  creation  and  analysis, 
and  sequence  determination.  It  also  provides  the 
logical  errors  that  may  be  detected  by  each  subphase; 
the  corresponding  messages  are  referred  to  by  the  refer- 
ence numbers  of  Table  6.3. 

Each  subphase  must  be  repeated  once  for  every  test 
module  in  the  whole  NOPAL  test  specification. 

6.3.1  CREATE  WEIGHTED  ADJACENCY  MATRIX,  W 

The  set  of  names  for  the  waveforms  (conjunctions 
or  assertions),  the  diagnoses,  and  the  variables  (local 
or  global)  appearing  in  a test  module  form  the  rows  and 
columns  of  the  weighted  adjacency  matrix,  W. 

Algorithm  6.2  gives  the  steps  of  creating  the 
weighted  adjacency  matrix  for  a given  test  module.  It 
begins  with  the  determination  of  the  size  of  the  matrix. 
Then  it  assigns  node  numbers  to  all  the  conjunctions 
and  assertions,  diagnoses,  and  the  variables  in  the 
test  module.  Next  it  allocates  the  matrix.  Finally  it 
initializes  the  matrix  to  all  zeros,  indicating  no 
relationship  between  any  pair  of  nodes  as  a default.  The 
matrix  is  now  ready  for  entering  precedence  relationships. 
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ALGORITHM  6.2  CREATE  WEIGHTED  ADJACENCY  MATRIX  FOR  A 
TEST  MODULE 

SI;  /*  Calculate  the  size  of  the  matrix  W */ 

Let  #W,  //D,  and  //V  be  respectively  the  number 
of  waveforms  (i.e.,  conjunctions  and  assertions), 
the  number  of  diagnoses,  and  the  number  of  variables 
(local  or  global)  in  the  given  test  module; 

Set  N = //W  + #D  + //V. 

S2:  /*  Assign  node  numbers  */ 

Successively  assign  node  numbers  (1  through  N) 
to  each  entity  (waveforms,  diagnoses,  and 
variables) ; 

Create  back-and-f o rth  linkage  pointers  so  that  if 

i ... 

, a node  number  is  given  then  the  storage  entry 

for  the  corresponding  entity  is  readily  accessible, 
andviceversa.  i 

S3:  Allocate  the  Weighted  Adjacency  Matrix  W as  an 

• NxN  matrix. 

( 

I 

I S4:  /*  initialize  W to  0 */ 

I » 

Set  W (i,j)  ■ 0,  (for  all  i,  j). 

i 

i S 5 : Return . 
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6.3.2  ENTER  PRECEDENCE  RELATIONSHIPS  INTO  MATRIX  W 


Two  types  of  precedence  relationships  may  exist 
among  the  entitles  in  a test  module.  Data  determinacv 
relationships  (type  1)  exist  between  a waveform  or 
diagnosis  which  defines  a variable  X as  TARGET  and  the 
variable  X,  also  between  a variable  Y and  a waveform 
or  diagnosis  which  uses  the  variable  Y as  SOURCE.  The 
principle  that  a data  must  be  generated  before  it  can 
be  used  is  thereby  guaranteed.  Waveform  setup  relation- 
ship (type  2)  exists  between  the  stimulus  conjunction 
and  the  measurement  conjunction.  This  ensures  that 
stimuli  are  applied  before  measurements  can  be  made 
under  normal  condition. 

The  data  determinacy  relationship  is  mandatory  and 
always  enforced,  hence  it  is  associated  with  the  highest 
priority,  1.  The  waveform  setup  relationship  is  implied 
only  if  the  measurement  conjunction  does  not  generate  a 
variable  which  is  in  turn  used  in  the  stimulus  conjunc- 
tion. Therefore,  this  relationship  is  associated  with  a 
lower  priority  2. 

Algorithm  6.3  shows  how  these  two  types  of  relation- 
ships are  detected  and  entered  in  the  weighted  adjacency 
matrix,  W.  If  both  the  stimulus  conjunction  and  measure- 
ment conjunction  are  not  null,  then  type  2 (waveform 
setup  relationship)  is  entered  in  the  matrix  W in  the  row 
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ALGORITHM  6.3  DETECT  AND  ENTER  WAVEFORM  SETUP  AND 
DATA  DETERMINACY  RELATIONSHIPS  FOR  A 
TEST  MODULE 

SO:  Define  data  determlnacy  relationship  as  precedence 

type  1,  priority  I,  and  waveform  setup  relation- 
ship as  precedence  type  2,  priority  2. 

SI:  /*  waveform  setup  relationship  */ 

If  stimulus  conjunction  or  measurement  conjunc- 
tion is  null,  then  go  to  S2. 

Sl.l:  Let  i and  j be  the  node  numbers  assigned 

to  the  stimulus  conjunction  and  measurement 
conjunction  respectively. 

SI. 2:  Set  W(i,j)  - 2. 

S2:  /*  data  determlnacy  relationships  in  waveforms  */ 

For  each  waveform  w in  the  test  module,  perform 
steps  S2.1  to  S2.3.2. 

S.2.1:  Let  i be  the  node  number  assigned  to  w. 

S.2.2:  /*  waveform  to  data  */ 

For  each  TARGET  variable  V in  the  wave- 
form w,  perform  steps  S2.2.1  to  S2.2.2. 
S2.2.1:  Let  j be  the  node  number 

assign.ed  to  V. 

S2 . 2 . 2 : Set  W(i , j ) - 1. 


S2.3:  /*  Data  to  waveform  */ 

For  each  SOURCE  variable  V in  the  waveform 
w,  perform  steps  S2.3.1  to  S2.3.2. 

S2.3.1:  Let  j be  the  node  number  assigned 

to  V. 

S2.3.2:  Set  W(j ,i)  - 1. 

S3:  /*  data  determinacy  relationships  in  diagnoses  */ 

For  each  diagnosis  d used  in  the  test  module, 
perform  steps  S3.1  to  S3. 3.2- 

S3.1:  Let  i be  the  node  number  assigned  to  d. 

S3. 2:  /*  operator  input  variables  */ 

For  each  operator  response  variable  V in  the 
diagnosis  d,  perform  steps  S3. 2.1  to  S3. 2. 2. 
S3. 2.1:  Let  j be  the  node  number  assigned 

to  V. 

S3. 2 . 2 : Set  W(i , j ) - 1. 

S3. 3:  /*  other  parameters  */ 

For  each  variable  V in  d's  other-parameters 
field,  perform  steps  S3. 3.1  to  S3. 3.2. 

53. 3.1  Let  j be  the  node  number  assigned 
to  V. 

53. 3. 2 SetW(j,i)«l. 

S 4 : Return. 
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and  the  column  corresponding  to  the  stimulus  conjunction 
and  the  measurement  conjunction  respectively  (steps  SI 
to  SI. 2).  Then  for  each  variable  (corresponding  to 
node  i)  in  a waveform  (conjunction  or  assertion,  corres- 
ponding to  node  j),  a data  determinacy  relationship 
(type  1)  is  entered  in  the  matrix  W,  in  the  row  i and  the 
column  j if  the  variable  is  defined  as  TARGET,  or  in  the 
row  j and  column  i if  the  variable  is  used  as  SOURCE 
(steps  S.2  to  S.2.3.2).  This  indicates  that  a waveform 
defining  a TARGET  variable  is  a predecessor  of  the 

variable,  and  similarly  a waveform  using  a SOURCE  vari- 

) 

able  is  a successor  of  the  variable.  Finally,  for  each 
variable  (corresponding  to  node  i)  in  a diagnosis 
(corresponding  to  node  j),  a data  determinacy  relation- 
ship (type  1)  is  entered  in  W,  in  the  row  i and  column  j 
if  the  variable  is  an  operator  input  variable  or  in  the 
row  j and  column  i if  the  variable  is  one  of  the  other 
parameters  in  the  diagnosis  (steps  S3  to  S 3 . 3'.  2 ) . This 
means  that  an  operator  input  variable  in  a diagnosis 
plays  the  same  role  as  a TARGET  variable  in  a waveform, 
and  a variable  in  the  other  parameters  of  a diagnosis 
plays  the  same  role  as  a SOURCE  variable  in  a waveform. 

6.3.3  GRAPH  ANALYSIS  OF  ADJACENCY  MATRIX  FOR  A TEST 
MODULE 

After  all  the  precedence  relationships  have  been 
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entered  into  the  weighted  adjacency  matrix,  the  matrix 
may  optionally  be  printed  out  for  user's  inspection. 

For  examp  le , ’‘Figur  e 6.4  shows  the  matrix  for  the  test 
module  FREQ  in  the  sample  test  specification  MINIRADIOSET 
of  Figure  3.2.  To  the  left  of  the  matrix  are  node 
numbers,  entity  names,  and  entity  types  (conjunction, 
assertion,  diagnosis,  or  variable). 

The  weighted  adjacency  matrix,  W,  is  now  ready  for 
further  analysis  to  detect  possible  logical  errors.  But 
to  speed  up  processing  and  for  the  purpose  of  cycle 
detection  in  the  next  stage,  an  adjacency  matrix.  A, 
corresponding  to  W is  generated  as  follows: 

A(i,j)  - 1 if  W(i,j)  > 0; 

_ “0  otherwise. 

Four  types  of  analysis  which  are  performed  at 
this  stage  are  summarized  in  the  following: 

(a)  If  there  exist  multiple  TARGET  definitions 
for  a variable,  then  a warning  (Message  #3)  is  sent  to 
the  user  indicating  that  they  must  be  under  mutually 
exlusive  condition.  This  is  detected  by  examining 
the  column  in  A for  each  variable.  If  such  a column 
has  two  or  more  entries  of  I's,  i.e.,  given  1 be  the 
node  number  for  the  variable,  there  exist  j and  k such 
that  j?*k  and  A(j,i)  » A(k,i)  « 1,  then  the  warning 


message  is  sent. 
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FIGURE  6.4  WEIGHTED  ADJACENCY  MATRIX  FOR  TEST  MODULE  FREQ. 


(b)  If  there  are  two  or  more  TARGET  variables 
declared  in  an  assertion,  then  it  is  an  error  of 
ambiguity.  The  way  to  detect  this  error  is  to  examine 
the  row  in  A for  each  assertion.  If  such  a row  has 
more  than  one  1-entry,  i.e.,  given  i be  the  node  number 
for  the  assertion  there  exist  j and  k such  that  j/k 
and  A(i,j)  » A(i,k)  = 1,  then  the  error  message  is  sent 
to  Che  user  (Message  //4). 

(c)  If  an  assertion  has  a TARGET  variable  but  the 
relation  operator  is  not  an  equal  sign  ('='),  then  a 
warning  of  inconsistency  is  sent  to  the  user  ^[Message  /(7), 
and  the  system  takes  an  action  of  setting  the  relation 
operator  to  a equal  sign. 

(d)  If  an  assertion  has  a TARGET  variable  X,  but 
the  expression  preceding  the  equal  sign  ('*')  in  the 
assertion  does  not  match  the  variable  X,  then  an  error 
of  ambiguity  is  issued  (Message  #6). 

Note  that  cases  (c)  and  (d)  can  be  detected  by 
first  examining  the  row  for  an  assertion  in  the  adjacency 
matrix  A to  determine  the  number  of  TARGET  variables 
defined  in  the  assertion.  If  there  exists  no  T.^RGET 
variable  in  the  assertion, then  both  cases  (c)  and  (d) 
need  not  be  checked.  If  there  is  more  than  a TARGET 
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variable, then  case  (b)  must  have  already  detected 
and  (c)  and  (d)  should  be  skipped.  .Thus,  if  there 
is  exactly  only  one  TARGET  variable  in  an  assertion, 
then  the  assertion  statement  must  further  ,be  retrieved 
to  check  the  relational  operator  and  the  expres’sion 
preceding  the  operator. 

If  any  errors  have  been  detected  during  this  stage, 
the  Processor  proceeds  to  the  next  subphase  of  cycle 
detection,  but  will  skip  the  last  subphase  of  sequence 
determinat ion . 

6.3.4  CYCLE  DETECTION  AND  ELIMINATION 

This  subphase  deals  with  another  important  type 
of  analysis  of  the  digraph.  "It  performs  the  tasks  of 
cycle  detection,  enumeration,  and  elimination.  This 
is  needed  in  order  to  1)  detect  cycle  and  eliminate 
them  automatically  if  possible,  and  2)  report  to  the 
user  about  erroneous  circular  definitions. 

In  order  to  do  such  analysis,  a path  matrix  (or 
reachability  matrix)  of  the  digraph  is  generated.  A 
path  matrix,  P ,•  is  a nxn  matrix  consisting  of  I's  and 
O’s,  with  a 1 in  row  i and  column  j if  and  only  if 
there  is  a "path"  from  the  node  i to  node  j,  i.e.,  node 
j can  be  "reached"  from  node  i by  tracing  the  edges 
of  the  digraph. 
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Formally,  a path  in  a digraph  is  a sequence  of 


edges  of  the  form  (vj^,  V2),  (v^  , ^ Vj^)  . 

The  path  is  said  from  node  and  of  length 

(k-1).  A path  is  s imp  1 e if  all  edges  and  all  nodes 
on  the  path,  except  possibly  the  first  and  the  last 
nodes,  are  distinct.  A cycle  is  a simple  path  of  length 
at  least  1 which  begins  and  ends  at  the  same  node 
[AHO  74].  Finally,  a path  matrix,  P,  for  a digraph 
can  be  defined  by  the  adjacency  matrix  as  follows: 


P(i,j)  = 1 if  A ( i , k^) =A (k^ , ) = ...=  A(k^,  j) 

“ 1,  for  some  k , k , ...,  k , and  m: 

^ m 

“ 0 otherwise . 

Equivalently,  P can  be  defined  as 
P » A + A^  + . . . + a'' 

where  n is  the  total  number  of  nodes  in  the  digraph 
and  '+'  denotes  logical  disjunction  (OR  operation). 

A more  efficient  way  of  generating  the  path  matrix 
from  an  adjacency  matrix  is  Warshall's  algorithm, 
which  is  as  follows: 


ALGORITHM  6,4  WARSHALL'S:  CREATE  PATH  MATRIX 


SI: 

Set 

P(i,  j) 

- A(i , j ) , for  all  i , j 

S2  : 

Set 

j“l 

S3  : 

Set 

i-1 

S4  : 

If 

P(i,  j) 

= 0 then  goto  S6 . 

S5:  For  k*l  to  n,  set  P(i,k)  + P(j,k). 

S6 : Set  i • i+1 ; 

If  i < » n then  goto  S4. 

S7:  Set  j » j+1; 

If  j < “ n then  goto  S3. 

S 8 : Return . 

In  the  above  algorithm,  n is  the  total  number 
of  nodes  in  the  digraph  (i.e.,  the  size  of  the  matrix 
A or  P) , and  in  the  step  S5  denotes  logical  OR. 

Once  the  path  matrix,  P has  been  created,  whether 
there  are  cycles  in  the  digraph  can  be  easily  detected 
by  examining  the  diagonal  of  P.  If  there  is  at  least 
one  1-entry  on  the  diagonal,  then  it  means  there  exists 
some  cycles  in  the  digraph;  otherwise  the  digraph  is 
cycle-free  (called  acy lie  digraph) . If  there  are  no 
cycles,  then  the  Processor  proceeds  to  the  next  sub- 
phase of  sequence  determination.  Otherwise,  each 
distinct  cycle  must  be  identified  and  examined.  If 
all  the  edges  in  the  cycle  are  of  precedence  priority  1 
(in  the  case  of  internal  analysis  it  turns  out  to  be 
precedence  type  1 only)  , then  it  is  an  error  of  circular 
definition  and  the  corresponding  message  including  those 
entities  in  the  cycle  is  sent  to  the  user  (Message  #5). 

If  there  exists  an  edge  of  lower  priority  (i.e.,  priority 
number  greater  than  1) , then  the  edge  is  removed  from  the 


digraph.  Eventually  either  the  digraph  becomes  cycle 
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free  or  all  the  unbreakable  cycles  are  detected  and 
reported  to  the  user.  The  Algorithm  6.5  identifies 
and  enumerates  distinct  cycles,  and  tries  to  break  them 
if  possible.  It  is  expanded  from  the  Algorithm  CYCLES 
in  [RIN  76]  which  was  adapted  from  [BER  71,  FLO  67]. 

The  expansion  involves  the  automatic  cycle  elimination 
once  a cycle  is  identified  (steps  S24  to  S24.7  of 
Algorithm  6.5). 

The  algorithm  has  five  inputs:  the  total  number 

of  nodes  in  the  digraph,  n;  the  adjacency  matrix.  A; 
the  path  matrix,  P;  the  weighted  adjacency  matrix  W; 
and  the  precedence  priority  vector  PRIORITY.  The  first 
three  parameters  are  needed  in  enumerating  all  distinct 
cycles;  while  the  last  two  parameters  are  required, 
in  addition,  in  the  process  of  cycle  elimination.  The 
algorithm  determines  all  cycles  by  the  basic  principle 
that  node  i is  in  a cycle  with  node  k if  A(i,k)  & P(k,i) 

* 1,  i.e.,  there  is  an  edge  from  node  i to  node  k and  a 
path  from  k back  to  i.  From  each  node,  it  successively 
grows  a tree  by  adding  a tree  edge  (i,k)  such  that 
A(i,k)  & P(k,i)  “ 1.  Whenever  a terminal  node  (i.e., 
a leaf)  of  a tree  coincides  with  the  root  of  the  tree, 
the  path  from  the  root  to  the  leaf  forms  a distinct  cycle. 

After  a cycle  is  found,  the  algorithm  tries  to 
eliminate  it  by  deleting  an  edge  which  has  lowes  t 
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.ALGORITHM  6.5  CYCLE  ENUMERATION  AND  ELIMINATION 
SI:  Set  ROOT  = 1. 

S2:  /*  initializations:  S2  to  S6  */ 

Set  REACH J(k)  = ROOT,  for  each  k = ROOT  to  n, 

S3:  Set  USED(k)  =0,  for  each  k = ROOT  to  n. 

S4:  Set  LEVEL  = 1. 

S5:  Set  PATH(l)  = ROOT. 

S6:  Set  i = ROOT. 

S7:  /*  Test  if  path  can  be  extended  with  nodes  in  a cycle: 

S7-S11  */ 

If  REACKJ(i)  > n then  go  to  step  S12. 

S3:  Set  j = RE/\CHJ(i). 

S9:  If  A(i,j)  6 P(j,ROOT)  = 1 and  USED(j)  = 0 

then  go  to  step  SI 8. 

SIO:  Set  j = j+1 , 

Sll:  If  j <=  n then  go  to  step  S9. 

S12:  /*  Backtrack  in  tree,  reset  REACHJ  + USED:  S12-S17  */ 

Set  RFACdJ(i)  = ROOT. 

SI 3:  Set  USED(i)  = 0. 

S14:  Set  LEVEL  = LF\/EL  - 1. 

S15:  If  LEVEL  = 0 then  go  to  step  S26. 

SIO:  Set  i = P.ATH ( LEVEL) . 

S17:  Go  to  step  S7. 

S18:  /*  extend  path:  S18-S23  */ 

Set  USED(j)  = 1 

'■et  PEAQ'Trj^  = 


^40 


LEVEL  + 1. 


S20:  Set  LEVEL  » 

S21:  Set  PATH(LEVEL)  = j . 

S22:  Set  i-j  . 

S23:  If  j ROOT  then  go  to  step  S7. 

S24:  /*Delete  an  edge  of  the  cycle  if  possible; 

otherwise  print  the  cycle  with  an  error  message 
S24-S24.8.  Notations  used:  pi  = lowest  pre- 
cedence priority;  (p,s)  = edge  deleted;  d = 
level  of  the  node  p in  PATH;  prty  = precedence 
priority  */ 

Set  pi  •>  1 . 

S24.1:  /*  Search  each  edge  in  the  cycle  */ 

For  k.“  1 to  (LEVEL-1),  perform  steps  S24.1  to 


S24. 6. 
S24. 1.1: 

S 2 4 . 1 . 2 : 

524. 1. 3 : 

524 . 1 . 4 : 

524. 1. 5 : 


/*  get  an  edge  (p,s)  */ 

Set  p=PATH(k)  and  s-PATH  (k+1). 

/*  priority  of  the  edge  */ 

Set  prty  = PRIORITY  (W(p,s)). 

If  prty  < = pi  then  go  to  S24.1.5. 
/*  lowest  priority;  save  level  */ 
Set  pl=  prty  and  d = k. 

/*  end  of  looping  k */ 


247 


S24 . 2 
S24.  3 

524. 4 

524. 5 


524. 6 

524. 7 

524. 8 

S25  : 
S26: 
S27  : 
S28: 


If  pi  • 1 then  go  to  S24.8. 

/*  Get  the  edge  having  priority  > 1 */ 

Set  p - PATH(d)  and  s - PATH(d+l). 

/*  Delete  the  edge  by  zeroing  A(p,s)  & W(p,s)  */ 
Set  A(p,s)  ■ 0 and  W(p,s)  » 0. 

/*  Backtrack  the  tree  to  node  p (i.e.,  level  d)  */ 
For  k * (d+1)  to  LEVEL,  perform  step  S24.5.1. 
S24.5.1:  /*  Reset  USED  */ 

Set  USED(PATH(k) ) - 0. 

Set  LEVEL  - d. 

Goto  step  S16 . 

/*  All  edges  have  priority  1;  print  the  cycle  */ 
print  the  cycle:  PATH(k),  for  k-1  to  level 
(Message  //5). 

Goto  S13. 

Set  ROOT  - ROOT  +1. 

If  ROOT  < * n then  go  to  S2. 

Return. 
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precedence  priority  other  than  priority  1 (i.e.,  the 
highest  priority).  The  algorithm  first  searches  all 
edges  in  the  cycle  and  finds  an  edge  (p,s)  having  lowest 
possible  priority  (steps  S24  to  S24.1.5).  If  this  edge 
has  priority  1,  then  so  does  every  edge  in  the  cycle, 
hence  Message  #5  including  the  cycle  is  printed  out 
(step  S24.8).  Otherwise,  the  edge  (p,s)  is  deleted  by 
setting  the  corresponding  entries  A(p,s)  and  W(p,s)  to 
zero  (steps  S24.3  and  S24.4).  Then  it  backtracks  to 
the  tail  (node  p)  of  the  deleted  edge  of  the  tree  and 
continues  (steps  S24.5  to  S24.7). 

To  further  illustrate  the  algorithm.  Figure  6.5 
shows  a digraph,  together  with  all  the  trees  constructed 
by  the  algorithm,  the  cycles  eliminated,  and  the  cycles 
printed  out.  All  the  edges  in  the  digraph  are  assumed 
to  have  precedence  priority  1,  except  for  the  edge  (3,4) 
which  takes  a lower  priority,  say,  2.  The  dotted  tree 
edges  denote  the  additional  ones  which  would  have  been 
constructed  by  the  algorithm  if  the  edge  (3,4)  had  not 
been  deleted.  Note  that  the  algorithm  works  on  the 
cycles  and  prints  them  in  ascending  order  of  the  node 
numbers.  This  example  is  adapted  from  [BER  71]. 

Having  created  the  adjacency  matrix,  analyzed 


it  for  consistency  and  completeness,  and  enumerated/ 
eliminated  cycles,  the  Processor  finishes  the  phase  of 
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analysis.  If  there  are  no  logical  errors,  such  as 
inconsistencies,  ambiguities,  incompleteness,  and 
illegal  cycles,  detected  in  this  phase,  the  Processor 
proceeds  to  the  subsequent  phases  of  sequence  deter- 
mination and  code  generation.  Otherwise,  the  Processor 
stops  processing  and  asks  the  user  to  correct  the  errors 
in  the  test  specification  and  resubmit.  In  this 
case,  it  has  provided  the  user  with  various  reports  pin- 
pointing the  causes  of  the  problems  and  suggestions  for 
corrections . 

6.3.5  INTRA-TEST-MODULE  SEQUENCE  DETERMINATION 

The  task  in  this  subphase  is  to  analyze  the  cycle- 
free  digraph,  represented  by  weighted  and  unweighted 


adjacency  matrices,  for  the  purpose  of  determining  the 
sequences  of  events  in  a test  module  according  to 
precedence  relationships  and  then  to  reorder  the  nodes 
based  on  their  rank. 

One  way  of  sequencing  the  nodes  in  an  acyclic  digraph 
is  summarized  in  Figure  6.6.  It  assigns  to  the  current 
rank  all  the  nodes  which  have  no  incoming  edges  from 
other  nodes.  Then,  it  deletes  all  such  nodes  (including 
the  corresponding  edges)  from  the  digraph.  If  the  result- 
ing digraph  is  empty,  then  the  algorithm  stops  with  all 
nodes  already  assigned  to  some  rank  value.  Otherwise,  it 
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increments  the  current  rank  and  repeats  the  process. 

This  algorithm  can  easily  be  implemented  non-p ic t or i a 1 ly 
by  using  an  adjacency  matrix  and  a "flag"  vector,  as 
shown  in  Algorithm  6.6. 

Another  method  of  ranking  the  nodes  of  a digraph 
is  to  multiply  the  -ad j acency  matrix.  A,  by  itself 
successively  [ e . g .,  BER  71].  At  each  stage,  the  nodes 
which  have  all-zero  column  are  assigned  to  the  current 
rank.  Then,  the  current  rank  is  incremented  and  the 
process  is  repeated. 

A variation  from  Algorithm  6.6  is  used  in  the 
current  implementation,  and  is  presented  in  Algorithm 
6.7.  This  is  adopted  from  the  algorithm  PRECED  [RIN  76], 
which  the  current  author  happened  to  help  develop  and 
implement.  The  algorithm  starts  by  finding  all  the 
nodes  with  no  incoming  edges,  and  assigning  them  to 
rank  0(step  S2).  Then,  the  nodes  of  rank  (i+1)  are  all 
the  nodes  which  are  the  direct  descendants  of  some  nodes 
of  rank  i (steps  S4  to  S7).  Note  that  the  rank  of’  some 
nodes  may  dynamically  be  updated.  After  all  the  nodes 
have  been  partitioned  into  "rank  sets",  the  algorithm 
then  proceeds  to  re-arrange  the  nodes  according  to  their 
rank  (steps  S12-S18).  The  final  result  is  an  "order 
vector"  ORDER,  where  ORDER(i)  is  the  node  number  which 
is  to  be  executed  at  step  i. 
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ALGORi™  6.6  NON- PICTORIAL  IMPLEMENTATION  OF  FIGURE  6.6 
SI;  /*  Initialize  "flag"  vector,  USED,  and  level  */ 

Set  USED(i)  = 0,  for  all  i a 1 to  n; 

Set  level  * 0. 

ft 

S2:  /*  Initialize  old  set  R1  to  contain  all  nodes  vdth  no  incoming 

edges  */ 

Let  R1  = ^j  j A(i,j)  = 0,  for  all  i = 1 to  n ^ 

S3:  /*  All  nodes  in  R1  are  ranked  as  "level",  and  flagged  */ 

^ Set  RANK(j)  = level  and 

Set  USED(j)  = 1,  for  all  j=l  to  n. 

S4;  /*  Increment  rank  level  */ 

Set  level  = level  +1;  ^ 

If  level  = n then  go  to  S9. 

S5:  /*  Create  new  set  R2,  consisting  of  all  non- flagged  direct 

descendants  of  R1  */ 

Let  R2  = I ACi,j)  =i  § USED(j)  = 0,  for  some  i in  Rl^ 

S6:  If  R2  is  empty,  then  go  to  SIO. 

S7;  /*  Update  old  set  Rl;  all  nodes  in  R2  which  have  no  incoming 

edges  from  unflagged  nodes  */ 

Let  Rl  = I j € R2  I A(i,j)=  0 or  USED(i)  = 1,  for  all  i j- 
S8:  Go  to  S3. 

S9:  Return,  /*  Error:  there  exists  a cycle  V 
SIO:  Re-arrange  the  nodes  according  to  their  rank. 

Sll:  Return. 

I 
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ALGORITHM  6.7  PRECEDENCE  SEQUENCE  DETERMINATION  j 

SI:  /*  Initialize  rank  vector  RANK  to  zeros  */  , 

i 

Set  RANKCi)  = 0,  for  i=l  to  n. 

S2:  I*  Old  set  R1  initially  consists  of  all  nodes  having  no 

predecessors  */ 

Let  R1  = ^j  I A(i,j)  = 0,  for  all  i = 1 to  n | 

S3:  If  R1  is  empty  then  go  to  Sll. 

S4:  Set  level  = 1. 

S5:  /*  New  set  R2  consists  of  all  nodes  \diich  are  the  direct 

successors  of  some  nodes  in  R1  */ 

Let  R2  = ^ j I A(i,j)  = 1,  for  some  i in  R1  j 
S6:  /*  All  nodes  in  the  new  set  R2  are  ranked  "level"  */ 

S7:  Set  RANK(j)  = level,  for  each  j in  R2. 

S8:  If  R2  is  empty  then  gc  to  S12. 

S9:  /*  Make  the  new  set  the  old  set  */ 

Set  R1  = R2. 

SIO:  Set  level  = level  + 1. 

If  level  < n then  go  to  S5. 

Sll:  /*  error:  some  cycles  exist  in  digraph  */ 

Return , 

S12:  /*  Normal  exit*,  rearrange  nodes  according  to  RANK  */ 

Set  k = 0 , 

S13:  For  i = 0 to  (level-1),  perform  steps  S14  to  S18. 

S14:  For  j = 1 to  n,  perform  steps  SI 5 to  SI 8. 

SIS:  If  RANKCj)  ^ i then  go  to  S18. 
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S16:  Set  k = k+1. 

S17:  Set  ORDER(k)  = j. 

S18:  /*  end  of  looping  i and  j */ 


S14 : Return. 


Figure  6.7  shows  the  rank  sets  and  order  vector 
produced  by  applying  this  algorithm  to  the  corresponding 
adjacency  matrix  of  Figure  6.4  (which  in  turn  corresponds 
to  a test  module  in  the  sample  problem  of  Figure  3.2). 
Since  nodes  of  the  same  rank  level  can  come  in  any  order, 
l.e.,  they  can  occur  in  parallel,  the  sequence  of  the 
nodes  generated  here  from  the  algorithm  is  not  unique. 

This  sequence  of  nodes  is  the  backbone  subsequently 
used  in  the  next  phase  of  code  generation  for  each  test 


module . 


6.4  INTER-TEST-MODULE  ANALYSIS  AND  SEQUENCING 


This  section  deals  with  the  creation  and  analysis 
of  the  digraph  for  the  whole  NOPAL  test  specification, 
and  the  determination  of  execution  sequence  of  test 
modules.  All  the  logical  errors  that  may  be  detected 
in  this  phase  are  also  properly  identified. 

In  this  process  of  inter-tes t-module  analysis  and 
sequencing,  each  test  module  is  considered  as  an  integral 
unit.  Although,  various  information  in  each  test  module 
may  be  collected  and  analyzed  to  determine  precedence 
relationships.  Various  precedence  relationships  with 
their  recognition  rules  have  been  summarized  in  Table 
6.1.  This  set  of  rules  is  by  no  means  exhaustive,  but 
extensible  to  include  additional  strategies  that  may  be 
found  useful.  Each  precedence  relationship  corresponds 
to  a row  in  the  table.  It  is  identified  by  a precedence  i 

type,  and  associated  with  a priority  and  a strategy  name. 

her.  its  existence  between  a predecessor  and  a successor 
is  specified,  possibly  with  an  execution  time  condition. 

A relationship  with  an  execution  time  condition  means 
that  this  condition  must  be  tested  dynamically  during 
execution  time.  These  relationships  are  then  used  to  form 
a digraph.  Each  node  of  the  graph  represents  a global 
data  (variable),  a diagnosis,  or  a test  module.  Each 
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directed  edge  denotes  one  of  these  precedence  relation- 
ships. Based  on  this  graph,  the  consistency,  complete- 
ness, and  ambiguity  of  the  specification  can  be  checked. 
Also,  test  modules  thereby  are  ordered  in  proper 
execution  sequence. 

The  six  sequencing  strategies  in  Table  6.1  are 
briefly  explained  in  the  following. 

1)  Data  determine cv  incorporates  the  principle 
that  data  must  be  generated  before  it  can  be  used.  The 
generation  of  data  by  a predecessor  test  module  is 
recognized  by  the  declaration  of  a TARGET  variable.*  A 
successor  test  module  references  the  same  variable, 
declared  as  SOURCE.  This  relationship  is  designated  as 
type  1,  and  is  mandatory.  Therefore,  it  is  associated 
with  a highest  priority  1. 

2)  Interactiveness  relationships  are  dictated  by 
the  need  to  exchange  messages  interactively  with  the 
ATE  operator.  Its  predecessor  is  a diagnosis,  and 
successor  a test  module,  which  is  connected  with  the 
diagnosis  by  a logical  operator  ''After"  (A)  or  "After- 
not"  (A-i  ).  Thus,  two  precedence  types  2 and  3 are 
given,  which  correspond  to  the  use  of  logical  operator 

A and  A— i respectively.  This  relationship  is  mandatory 
and  conditional  on  actual  selection  (or  non-selection) 
of  the  diagnosis  at  run  time.  Once  the  predecessor 
diagnosis  is  selected  (or  not  selected),  the  successor 
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test  module  should  be  executed  next. 


3)  Component  protection  is  based  on  the  concept 
that  non-destructive  testing  can  be  achieved  if  a critical 
component  is  tested  before  other  components  which  depend 
on  it  for  their  normal  operation.  Hence,  the  failure 
of  such  a critical  component  will  prohibit  further 
testing  for  those  dependent  components.  This  relationship 
is  derived  from  the  information  on  the  protection  field 
in  the  UUT  Component  Failures  specification.  This  is 
mandatory  and  run-time  conditional. 

Fault  isolation  strategy  schedules  tests  in 
a top-down  fashion  using  component  subset  relationships. 
The  more  generic  fault  isolation  tests  are  performed 
first.  The  lower  level,  more  specific  tests  are  then 
executed  or  skipped,  depending  upon  whether  the  failure 
is  detected  at  the  top  level.  In  this  relationship,  the 
predecessor  is  a diagnosis,  D,  and  the  successor  is  a 
test  module  whose  set  of  affected  components  is  a sub- 
set of  the  set  of  affected  components  diagnosed  by  D. 

There  are  two  precedence  types  (5  and  6)  in  this  class. 

In  type  5,  the  diagnosis  D specifies  a set  of  affected 
components  in  disjunction.  For  instance,  if  D is 
selected,  the  component  a oj  b or  c is  in  failure.  In 
this  case,  a test  module  that  may  result  in  diagnosis  of 
a subset  of  components,  say,  a and/or  b,  is  executed 
next  to  isolate  the  faults  more  specifically.  On  the 
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other  hand,  if  the  diagnosis  D is  not  selected,  then 
such  a test  module  will  not  be  scheduled  for  execution. 

In  the  other  type  6,  the  diagnosis  D specifies  a set 
of  affected  components  in  conjunction  (e.g.,  a and  b and 
c).  If  D is  selected,  then  it  means  that  components  a 
and  b and  c are  defective.  Therefore  any  test  module 
which  may  result  in  diagnosing  a subset  of  components, 
say,  a and/or  b,  will  not  be  executed  since  the  faults 
have  already  been  isolated.  Otherwise,  D is  not  selected 
and  then  such  a test  will  be  performed  next  to  further 
identify  the  failure.  Like  precedence  types  2,  3 and 
4,  these  two  types  of  fault  isolation  are  conditional 
with  a checking  of  the  predecessor  diagnosis  at  run  time. 

5)  Stimuli  application  is  concerned  with  efficient 
application  of  waveform  stimuli.  It  is  based  on  the 
assumption  that  application  of  stimuli  is  most  time- 
consuming,  hence  it  is  advisable  to  conduct  all  the 
possible  tests,  once  a stimulus  is  applied.  Test 
modules  which  have  stimuli  triplets  with  higher  frequency 
are  predecessors  to  modules  with  lower  frequency  of 
stimuli  triplets. 

6)  Failure  likelihood  uses  the  idea  that 
efficiency  is  obtained  by  first  testing  those  components 
which  are  more  likely  to  fail.  Information  is  extracted 
from  the  failure  index  field  in  the  UUT  Component 
Failures  specification.  Type  10,  with  priority  4 is 
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given  to  this  relationship. 

In  addition  to  the  types  of  relationships  discussed 
in  the  above  six  strategies,  five  other  types,  11  through 
15,  are  given  between  a test  module  and  a diagnosis  which 
is  selected  in  the  test  module  by  logical  operators  * 
(don't-care),  [(or),  |-i(or-not),  &(and),  and  &-i(and- 
not)  respectively.  The  basic  idea  is  that  a diagnosis 
is  posted  after  its  predecessor  test  module  finishes 
execution.  These  five  types  could  be  combined  into  one 
single  type,  but  they  are  made  distinct  in  order  to 
speed  up  later  processing. 

All  these  precedence  types  are  extracted  from  the 
NOPAL  specification  and  put  into  a weighted  adjacency 
matrix  as  discussed  in  the  subsequent  subsections. 

6.4.1  CREATE  WEIGHTED  ADJACENCY  MATRIX,  W 

The  rows  (and  columns)  of  the  weighted  adjacency 
matrix,  W (corresponding  to  the  digraph  of  the  whole 
NOPAL  test  specification)  consist  of  the  names  for  the 
test  modules,  the  diagnoses,  and  the  global  variables. 

The  layout  of  this  matrix  with  all  possible  precedence 
relationships  is  illustrated  in  Figure  6.8. 

The  steps  of  creating  the  weighted  adjacency  matrix 
are  summarized  in  Algorithm  6.8.  This  is  the  same  as 
Algorithm  6.2  except  that  the  matrix  represents  different 
set  of  entities.  It  first  obtains  the  size,  N,  of  the 
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DIAGNOSES  TESTS 


. :W. 


ALGORITHM  6.8:  CREATE  WEIGHTED  ADJACENCY  MATRIX  FOR 

NOPAL  SPECIFICATION 

SI:  /*  Calculate  size  of  the  matrix  W */ 

Let  #TESTS,  #DIAGS,  and  WARS  be  respectively  the  number  of 
test  modules,  the  number  of  diagnoses,  and  the  number  of  global 
variables  in  the  vdiole  NOPAL  specification; 

Set  N = #TESTS  + #DIAGS  + WARS 
S2:  /*  .Assign  node  numbers  */ 

Successively  assign  node  nunbers  (1  through  N)  to  each  entity 
in  SI; 

Create  back- and- forth  linkage  pointers,  so  that  if  a node  number 
is  given,  then  the  corresponding  storage  entry  is  readily 
accessible,  and  vice  versa. 

S3:  Allocate  the  weighted  adjacency  matrix,  W,  as  an  NxN  matrix. 

-S4 : /*  Initialize  W to  zero  */ 

Set  W(i,j)  » 0,  (for  all  i,  j). 

S 5 : Return. 


r 


■ ^ matrix  as  the  total  number  of  the  test  modules, 

diagnoses,  and  global  variables  in  the  NOPAL  specifi- 
cation (step  SI).  Then  it  assigns  node  numbers  to  all 

i 

such  numbers  to  all  such  entities,  allocates  the  matrix 
f W,  and  finally  initializes  W to  all  zeros  (steps  S2  to 

j S4). 

I 6.4.2  ENTER  PRECEDENCE  RELATIONSHIPS  INTO  MATRIX,  W 

! All  types  of  precedence  relationships  as  listed  in 

I 

; Table  6.1  are  extracted  from  the  NOPAL  test  specification 

1 

and  entered  into  the  weighted  adjacency  matrix,  W,  in 
the  following  subsections  (6. 4. 2.1  through  6. 4. 2. 6). 

6. 4. 2.1  ENTER  DATA  DETERMINACY  RELATIONSHIPS 

Data  determinacy  relationships  (type  1,  priority  1) 

I are  entered  into  the  weighted  adjacency  matrix  W between 

a test  module  defining  a global  variable  and  the  variable, 
also  between  a global  variable  and  a test  module  which 
references  the  variable. 

Algorithm  6.9  shows  how  data  determinacy  relation- 
ships trs  detected  and  entered  in  the  matrix  W.  Each 

n t#  If 

I 

I 


I 
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ALGORITHM  6.9  DETECT  AND  ENTER  DATA  DETERMINANCY 
RELATIONSHIPS 

SO:  Designate  data  determinacy  relationship  as  type  1, 

priority  1. 

SI:  For  each  test  module  t in  the  NOPAL  specification, 

perform  steps  S2  to  S7.2. 

S2:  Let  i be  the  node  number  assigned  to  the 

test  module  t. 

S3:  For  each  waveform  w in  test  module  t,  perform 

steps  S4  to  S5 . 2. 

S4:  /*  TARGET  global  variables  */ 

For  each  TARGET  variable  v in  the  waveform  w, 
perform  steps  S4.1  to  S4.2. 

S4.1;  Let  j be  the  node  number  for  the 
variable  v. 

S4.2:  If  SCOPE  of  v is  global,  then  set 

W(i,j)  - 1. 

S5;  /*  SOURCE  global  variables  */ 

For  each  SOURCE  variable  v in  the  waveform  w, 
perform  steps  S5.1  to  '5.2. 

S5.1:  Let  J be  the  node  number  for  the 

verlabLe  v. 

' * rt*  y i«  global,  then  set 


' • 


• i ■“ 


• « 


* t 


S7:  /*  SOURCE  global  variables  used  in 

diagnosis  */ 

For  each  variable  v in  the  other- 
parameters  of  the  diagnosis  d,  perform 
steps  S7.1  to  S7.2. 

S7.1:  Let  j be  the  node  number  for  v. 

S7.2:  If  SCOPE  of  v is  global,  then 

set  W(j , i)  « 1. 

S8:  For  each  diagnosis  d in  the  NOPAL  specification, 

perform  steps  S9  to  S10.2, 

3 

S9:  Let  i be  the  node  number  for  the  diagnosis  d. 

SIO:  /*  Operator  input  variables  — TARGET  */ 

For  each  variable  v in  the  operator  response 
variable  list  of  the  diagnosis  d,  perform 
steps  SlO.l  to  SIO, 2. 

SlO.l;  Let  j be  the  node  number  for  the 
va r i ab 1 e v . 

SIO. 2:  If  SCOPE  of  v is  global,  then  set 

W(l.j)  - 1. 


Sll  : 


Return. 


matrix  W in  row  i and  column  j to  indicate  that  the 


test  module  t is  a predecessor  and  the  variable  a 
successor  in  the  relationship  of  data  determinacy  (steps 
S4  to  S4.2).  Also,  for  each  SOURCE  variable  (correspond- 
ing to  node  j)  in  a waveform  or  diagnosis  of  the  test 
module  t,  type  1 is  entered  into  W in  row  j and  column  i, 
indicating  that  the  variable  is  a predecessor  of  t 
(steps  S5  to  S7.2).  Finally,  for  each  diagnosis  corre- 
sponding to  node  i)  in  the  NOPAL  specification,  if  its 
operator  input  variable  (corresponding  to  node  j)  is 
global,  then  type  1 is  entered  into  W in  row  i and 
column  j to  denote  that  the  diagnosis  is  the  predecessor. 

6, 4. 2. 2 ENTER  INTERACTIVENESS  AND  LOGICAL  OPERATOR 
RELATIONSHIPS 

Interactiveness  relationships  are  entered  between 
a diagnosis  and  a test  module  connected  by  logical 
operator  A (type  2)  or  A— i (type  3).  The  remaining 
logical  operators  (*,  [ , |-i , &,  & -t  ) are  used  to  enter 

logical  operator  relationships  (types  11  through  15) 
between  test  modules  and  diagnoses  connected  by  the 
respective  logical  operators. 

Algorithm  6.10  shows  the  procedure  to  detect  and 
enter  these  relationships.  In  each  test  module  (corre- 
sponding to  node  1).  the  logic-diagnosis  list  is  examined 


s t • : » 5 1 to  3 5 


Depending  on  the  logical  operator 


ALGORITHM  6.10  DETECT  AND  ENTER  INTERACTIVENESS 

AND  LOGICAL  OPERATOR  RELATIONSHIPS 


SO:  Designate  interactiveness  relationships  as 

type  2 for  logical  operator  A,  and  type  3 for 
A— t . Also  designate  logical  operator  relation- 


ships as  types  11  through  15  for  logical 
operators  *,  | , |— i , &,  and  &— »,  respectively. 

SI:  For  each  test  module  t in  the  NOPAL  specification 

perform  steps  S2  to  S5. 

■S2:  Let  i be  the  node  number  for  test  module  t. 

S3:  For  each  operator-diagnosis  pair  (op,  d)  in 

the  logic-diagnosis  list  of  t,  perform 
steps  S4-S5. 

S4:  Let  j be  the  node  number  for  diagnosis  d. 

S5:  If  op  = '?*  then  set  W(j,i)  =2;  /*  A */ 

else  if  op  = ' ? ' then  set  W(j,i)  = 3; 

/*  A-,  */ 

else  if  W(i,j)  ^ 0 then  give  error  (Message 

! 

#10)  ; 

else  if  op“'*'  then  set  W(i,j)  = 11; 
else  if  op  - 'I'  then  set  W(i,j)  » 12; 
else  if  op  ■ '1"^'  then  set  W(i,j)  ••  13: 
else  If  op  ■ then  set  W(i,j)  - 14; 


in  each  logic-diagnosis  pair,  different  types  of 
relationships  are  entered  between  the  test  module  and 
the  diagnosis  (corresponding  to  node  j).  If  the 
operator  is  A (after)  or  A— > (after-not),  then  type  2 
or  3 is  entered  into  matrix  W in  row  j and  column  i 
to  indicate  that  the  diagnosis  is  a predecessor  of  the 
test  module  by  interactiveness  relationship.  Otherwise, 
type  11,  12,  13,  14,  or  15  is  entered  into  W in  row  i 
and  column  j according  as  the  operator  is  *,  | , |~i  , 

&,  or  & — J respectively.  In  this  case,  the  diagnosis  is 
considered  to  be  a successor  of  the  test  module. 

6. 4. 2. 3 ENTER  COMPONENT  PROTECTION  RELATIONSHIPS 

Algorithm  6.11  shows  how  the  component  protection 
relationships  between  diagnoses  and  test  modules  are 
extracted  and  entered  into  the  weighted  adjacency 
matrix  W.  For  each  affected  component,  a set  T of  test 
modules  each  of  which  includes  it  as  an  affected  com- 

t 

ponent  is  obtained  first  (steps  SI  to  S3).  For  each 
element  in  the  component  protection  list  of  this  same 
affected  component,  another  set  D of  diagnoses  each  of 
which  includes  the  element  as  an  affected  component  is 
computed  next  (steps  S4  to  S5).  Finally,  for  each  diag- 
nosis (corresponding  to  node  1)  in  D,  and  for  each  test 
module  (corresponding  to  node  j)  in  T,  type  4 is  entered 
into  the  matrix  W in  row  i and  column  j indicating  that 
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ALGORITHM  6.11  DETECT  AND  ENTER  COMPONENT  PROTECTION 

RELATIONSHIPS 

SO:  Designate  component  protection  relationships  as 

type  4,  priority  1. 

SI:  For  each  affected  component  c in  the  UUT  specifi- 

cation of  component  failures,  perform  steps  S2 
to  Sll. 

S2:  If  component-protection  list  of  c is  null 

then  go  to  Sll. 

S3:  Let  Tc  be  the  set  of  test  modules  which 

include  c as  one  of  the  affected  components. 

S4:  For  each  affected  component  p in  c's  com- 

ponent-protection list,  perform  steps  S5  to 
SIO. 

S5:  Let  Dp  be  the  set  of  the  diagnoses  which 

include  p as  an  affected  component. 

S6:  For  each  diagnosis  d in’  Dp,  perform  steps 

S7  to  SIO. 

S7:  Let  i be  the  node  number  for  diagnosis 

d. 

S8:  For  each  test  module  t in  TC,  perform 

steps  S9  and  SIO . 

S9 : Let  j be  the  node  number  for  t. 

SIO:  If  W(i,  j)-  = 0,  then 
Set  W(i,j)  = 4; 

else  give  warning  (Message  #9). 

Sll:  /*  end  of  looping  each  c */ 

S 1 2 : Return. 
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the  diagnosis  precedes  the  test  module  by  component 
protection  relationship. 

6. 4. 2. 4 ENTER  FAULT  ISOLATION  RELATIONSHIPS 

Fault  isolation  (i.e.,  component  subset)  relation- 
ships are  detected  and  entered  into  the  matrix  W between 
a diagnosis  and  a test  module  whose  set  of  affected 
componen t s , is  a subset  of  that  of  the  diagnosis.  If 
the  diagnosis  identifies  affected  components  in  dis- 
junction, then  type  5 is  entered  in  the  proper  entry 
of  W.  Otherwise,  it  diagnoses  components  in  conjunction 
and  a type  6 is  entered. 

Algorithm  6.12  gives  the  steps  of  detecting  and 
entering  these  relationships.  First,  for  each  test 
module  t in  the  whole  NOPAL  specification,  a set 
of  distinct  affected  components  in  all  the  diagnoses 
of  the  test  module  t is  computed  (steps  SI  and  S2). 

Then,  for  each  diagnosis  (corresponding  node  i)  in  the 
NOPAL  specification,  another  set  D of  affected  com- 
ponents in  this  diagnosis  is  obtained  (steps  S3  and 
S4).  If  these  components  are  in  conjunction,  then  pre- 
cedence type  is  set  to  6;  otherwise  5 (step  S7).  Finally 
for  each  test  module  t (corresponding  to  node  j),  if 
is  not  empty  and  is  a proper  subset  of  D,  then 
the  precedence  type  is  entered  into  the  matrix  W in 
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ALGORITHM  6.12  DETECT  AND  ENTER  FAULT  ISOLATION 

RELATIONSHIPS 

SO:  Designate  fault  isolation  relat ionships as  types 

5 and  6,  both  with  priority  2. 

SI:  /*  Compute  affected-components  set  for  each  test 

module  */ 

For  each  test  module  t in  the  NOPAL  specification, 
/ performst.epS2. 

S2:  Let  C^  be  the  set  of  distinct  affected  com- 

ponents in  all  diagnoses  of  the  test  module  t. 
S3:  /*  Compute  a f f e c t ed- comp o nen t s set  for  each  diag- 

nosis, and  enter  component  subset  relationships  */ 
For  each  diagnosis  d in  the  NOPAL  specification, 
perform  steps  S4  to  Sll. 

S4:  Let  Cd  be  the  set  of  affected  components  in 

the  diagnosis  d. 

S5:  If  Cd  is  null,  then  goto  Sll. 

S6:  Let  i be  the  node  number  for  the  diagnosis  d. 
S7:  If  d's  affected  components  are  conjunctive 

then  set  ptype  *=  6; 
else  set  ptype  •=  5. 

S8:  For  each  test  module  t in  the  NOPAL  specifi- 

cation, perform  steps  S9  and  SIO. 

S9:  Let  j be  the  node  number  for  t. 

SIO:  If  C^  is  not  null  then  if  C^  is  properly 

contained  in  C^  then  set  WJ/{ , j ) - ptype. 

/ 

Sll:  /*  end  of  looping  each  diagnosis  */ 

S 1 2 : Return. 
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row  i and  column  j to  indicate  that  the  diagnosis  is 

a predecessor  of  the  test  module.  j 

i 

6. 4. 2. 5 ENTER  STIMULI  APPLICATION  RELATIONSHIPS  j 

Stimuli  application  relationships  (type  9)  are  ] 

entered  into  the  matrix  W between  test  modules  such  that  j 

the  predecessor  test  module  has  more  frequently  used  j 

stimuli  than  the  successor  does.  I 

Algorithm  6.13  shows  how  these  relationships  are  1 

extracted  and  entered  in  the  matrix  W.  It  begins  with  | 

the  calculation  of  stimuli  triplet  frequencies  (steps 
SI  to  S2.4).  The  frequency  of  a stimuli  triplet  is 
defined  as  the  total  number  of  occurrences  of  the  triplet 
in  all  the  test  modules.  Then  the  algorithm  indexes 
all  stimuli  triplets  in  decreasing  order  of  their 

frequencies  (steps  S3  to  S3. 2).  Next  it  obtains  the  | 

index  value  of  the  most  frequent  stimuli  triplet  (i.e., 
the  triplet  having  lowest  index  value)  in  each  test 
module  (steps  S4  to  S4.8).  Finally,  for  each  pair  of 
test  modules  (corresponding  to  nodes  i and  j)  if  the 
index  value  of  the  most  frequent  stimuli  triplet  in  test 
module  i is  smaller  than  that  in  test  module  j , then  a 
type  9 is  entered  into  the  matrix  W in  row  i and  column  j 
to  indicate  that  test  module  i is  a predecessor  by 
stimuli  application  relationship. 
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ALGORITHM  6.13  DETECT  AND  ENTER  STIMULI  APPLICATK^  RELATICNSHIPS 
SO;  Designate  stimuli  application  as  type  9,  priority  3. 

SI:  /*  Calculate  stimuli  triplet  frequencies: 

Let  s be  a stimuli  triplet  (i.e.,  <conn_dim_ex>  = 
<funcjdim_ex>  ) . then  the  frequency  of  s : 

Freq(s)  = total  number  of  occurrences  of  s 

in  all  test  modules  */ 

For  each  test  module  t in  the  NOPAL  specification,  perform 
steps  S2  to  S2.4. 

S2:  For  each  stimuli  triplet  s in  test  module  t,  perform 
steps  S2.1  to  S2.4. 

S2.1:  If  s is  not  yet  in  the  stimuli  triplets  stack,  then  add  s 
to  it  and  set  the  Freq  field  to  0. 

S2.2:  Let  p be  the  position  of  s in  the  stack. 

S2.3:  /*  Increment  frequency  */ 

set  Freq(p)  = Freq(p)  + 1. 

S2.4:  Add  to  the  triplet  list  of  test  module  t a cell  pointing 
to  p of  the  stack. 

S3:  /*  Index  all  stimuli  triplets  in  the  order  of  decreasing 

frequencies,  except  that  index  "null  stimuli"  1 */ 

Set  Indexfl)  * 1.  /*  null  stimuli  */ 

S3.1:  Sort  stack  entries  by  their  frequencies  (in  decreasing 
order  of  Freq) . 

S3. 2:  Set  "Index"  fields  of  the  sorted  stack  to  2,  3,  ... 
successively. 

S4:  /*  get  index  value  of  the  most  frequent  stimuli 

triplet  in  each  test  module  */ 

For  each  test  module  t,  perform  steps  S4.1  to  S4. 
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S4.1:  Let  i be  the  node  number  for  t. 


S4.2:  Let  lowindex  ■ Very-large#. 

S4.3:  Set  P ■ Listhead  (i). 

S4.4:  While  p ^ null,  perform  steps  S4.5  to  S4.6 

S4.5:  If  low-index  > Index  (Left) 

set  lowindex  « Index  (Left) 

S4.6:  Set  p - right. 

S4.7:  If  lowindex  » Very-large#  then 

set  lowindex  ■ 0. 

S4.8:  Set  lowix  (i)  ■ lowindex. 

S5 : /*  Enter  type  9;  For  all  i,j, 

• If  Index  (most  frequent  stimuli  triplet  of  test  i) 

< Index  (most  frequent  stimuli  triplet  of  test  j) 
then  W(i,j)  -9  */ 

For  i«l  to  (#TESTS  - 1),  perform  steps  S5.1  to  S5.4. 
S5.1:  Set  Ix  * Lowix  (i). 

S5.2:  For  j ••  (i+1)  to  #TESTS,  perform  steps 

S5. 3 to  S5. 4. 

S5.3:  Set  Jx  « Lowix  (j). 

S5.4:  If  Ix  < Jx  then 

set  A(i,j)  - 9 - 

else  if  Ix  > Jx  then 

/ 

Set  W(j  ,1)  - 9. 

S6 : Return. 
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To  illustrate  the  steps  in  Algorithm  6.13,  three 
data  structures  are  used  as  shown  in  Figure  6.9.  One 
is  a stack  for  all  stimuli  triplets,  which  consists  of 
three  fields:  1)  "Triplet"  for  storing  a stimuli  triplet, 
2)  "Freq"  for  frequency  of  the  triplet,  and  3)  "Index" 
for  index  value  of  the  triplet.  Another  stack  for  all 
test  modules  consists  of  two  fields:  1)  "Listhead" 
pointing  to  a list  of  stimuli  triplets  in  each  test 
module,  and  2)  "Lowix"  which  will  contain  the  index 
value  of  the  most  frequent  stimuli  triplet  in  each  test 
module.  The  last  data  structure  is  a collection  of  list 
cells  used  to  construct  linked  lists.  There  are  two 
fields  in  each  cell.  The  "Left"  points  to  a location 
in  the  stack  for  stimuli  triplets,  and  the  "Right" 
points  to  next  cell  in  the  list. 

6. 4. 2. 6 ENTER  FAILURE  LIKELIHOOD  RELATIONSHIPS 

Algorithm  6.14  shows  the  steps  of  detecting  and 
entering  the  failure  likelihood  relationships  into  the 
matrix  W between  test  modules.  Information  is  extracted 
from  the  failure-index  field  of  each  affected  component 
in  the  specification  of  UUT  component  failures. 

For  each  test  module  the  algorithm  obtains  the 
failure  index  of  the  affected  component  which  has  the 
lowest  assigned  value  of  failure  index  in  the  test  module 
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Figure  6 . 9 

Data  Structures  Used  in  Algorithm  6.13 
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ALGORITHM  6.14  DETECT  AND  ENTER  FAILURE  LIKELIHOOD  RELATIONSHIPS 
SO:  Designate  failure  likelihood  relationship  as  type  10,  priority  4. 

SI:  /*  For  each  test  module,  get  the  failure  index  of  the  affected 

component  which  has  lowest  value  of  failure -index  in  the  ^est 
module  */ 

For  each  test  module  t in  the  NOPAL  specification,  perform  steps 
S2  to  S6. 

S2:  Let  i be  the  node  number  for  test  module  t. 

S3:  If  all  the  affected  components  in  t have  not  been  assigned 
failure  indices,  then  set  FAIL_INDICES(i)  = 0 and  go  to  S6. 
S4:  Let  c be  the  affected  component  vdiich  has  lowest  assigned 
failure  index  in  the  test  module  t. 

S5:  Set  FAIL-INDICES (i)  = failure  index  of  c. 

S6:  /*  end  of  looping  each  test  module  */ 

S7:  /*  Enter  type  10  into  W(i,j),  if 

FAIL_INDICESCi)  < FAIL_INDICESCj)  V 

Let  #TESTS  be  the  total  nimiber  of  test  modules. 

S8:  For  i*l  to  (#TESTS-1) , perform  steps  S9  to  S19. 

S9:  Set  I^  = FAIL-INDICES (i) . 

SIO:  If  I^  = 0,  then  go  to  S19. 

Sll:  For  j = (i+1)  to  #TESTS,  perform  steps  S12  to  S19. 

S12:  Set  Jx  = FAIUJNDICES(j) . 

S13:  If  = 0,  then  go  to  S19. 

S14:  If  I < J then  go  to  S18. 
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S15: 

If 

I 

X 

- J 

X 

then  go 

to  S19 

S16  : 

/* 

I 

X 

> J 

X 

*/ 

If 

A(j 

,i)  - 

0 then 

set  A( j , i) 

1 

o 

S17: 

Go 

to 

S19. 

SIS: 

/* 

I 

X 

< J 

X 

*/ 

If 

A(i 

• j)  • 

0 then 

set  A(i,j) 

- 10. 

S19  : 

/* 

end 

looping  j & 

i */ 

S20;  Return. 


i 
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(steps  SI  to  S6).  Then  for  each  pair  of  test  modules 
(corresponding  to  nodes  i and  j),  if  the  lowest  assigned 
failure  index  of  the  affected  components  in  test  module 
i is  lower  than  that  in  test  module  j,  then  a type  10 
is  entered  into  the  matrix  W in  row  i and  column  j 
Indicating  that  test  module  i precedes  j by  failure 
likelihood  relationship. 

After  all  types  of  precedence  relationships  in  the 
NOPAL  specification  have  been  extracted  and  entered 
into  the  weighted  adjacency  matrix,  the  phase  of  graph 
creation  is  complete.  If  there  are  no  logical  errors 
detected,  then  the  Processor  continues  to  subsequent 
phases  of  analysis  and  code  generation.  Otherwise,  the 
Processor  stops,  and  the  user  has  to  resubmit  his  NOPAL 
test  specification  after  correcting  all  errors  as  pin- 
pointed by  various  reports  produced  so  far. 

6.4.3  GRAPH  ANALYSIS  OF  ADJACENCY  MATRIX  FOR  NOPAL 
SPECIFICATION 

At  this  stage,  all  precedence  relationships  have 
been  extracted  from  the  NOPAL  specification  and  entered 
into  the  weighted  adjacency  matrix.  This  matrix  may 
be  printed  out  at  the  discretion  of  the  user.  Figure 
6.2  shows  the  weighted  adjacency  matrix  for  the  sample 
test  specification  MINIRADIOSET  of  Figure  3.2. 
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The  task  of  this  phase  is  to  perform  further 
analysis  on  the  weighted  adjacency  matrix  to  detect 
possible  logical  errors.  The  problem  of  cycles  in  the 
digraph  is  dealt  with  separately  in  the  next  section. 

An  (unweighted)  adjacency  matrix.  A,  is  generated  from 
the  matrix  W for  the  purposes  of  more  efficient  pro- 
cessing and  later  cycle  analysis.  Each  entry  A(i,j) 
is  1 if  the  corresponding  entry  W(i,j)  is  non-zero. 
Otherwise  A(,i,j)  is  zero. 

Various  types  of  analysis  which  are  performed  in 
this  phase  are  summarized  as  follows: 

(a)  If  a variable  is  referenced  as  SOURCE  in  a 
test  module  but  the  variable  has  never  been  defined 
as  TARGET  in  any  other  test  module,  then  it  is  an  error 
of  incompleteness.  This  can  be  detected  by  examining 
the  column  for  each  variable  in  the  adjacency  matrix, 

A.  If  such  a column  is  all  zero,  Chen  an  error  message 
is  sent  to  the  user  (Message  #1). 

(,b)  On  the  other  hand,  if  a variable  has  been 
defined  as  TARGET  in  a test  module,  but  never  been 
used  as  SOURCE  in  any  other  test  module,  then  it  is  a 
situation  of  possible  incompleteness,  hence  a warning  is 
warranted.  The  way  to  detect  this  is  to  check  the  row 
in  A for  each  variable.  If  the  row  is  all  zero,  then 
a warning  is  sent  (Message  #2). 
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(c)  If  a global  variable  has  been  defined  as 
TARGET  in  more  than  one  test  module,  then  it  may  be 

an  error,  unless  it  is  under  mutual  exclusive  situation. 
This  is  detected  by  examining  the  column  for  each 
variable  in  the  matrix  A.  If  there  exist  two  or  more 
non-zero  entries  in  such  a column,  then  a warning  is 
printed  out  (Message  #3). 

(d)  If  there  is  no  diagnosis  ever  specified  in 
a given  test  module,  then  the  user  might  forget  to 
include  it  by  mistake,  hence  a warning  of  possible 
incompleteness  is  sent  (Message  #8).  To  detect,  the 
row  for  each  test  module  in  matrix  A is  examined.  If 
all  the  diagnosis  entries  of  such  a row  are  all  zero, 
then  there  is  no  diagnosis  at  all  in  the  test  module, 
hence  the  corresponding  warning  message  is  produced. 

(e)  To  achieve  interactiveness,  there  should  be  no 
more  than  one  successor  test  module  which  is  connected 
to  a given  diagnosis  by  the  same  logical  operator  A 

(or  A— 1 ).  This  situation  is  detected  by  examining  the 

row  for  each  diagnosis  in  the  weighted  adjacency  matrix 

W.  If  there  are  two  or  more  entries  of  2,  or  two  or 

more  entries  of  3 in  such  a row,  then  an  error  message 

is  sent  to  the  user  (Message  #15). 

After  these  checks  for  consistency,  completeness, 

and  unambiguity,  the  Processor  proceeds  to  next  sub- 
phase of  cycle  detection  and  elimination. 
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6.4.4  CYCLE  DETECTION  AND  ELIMINATION 

This  section  is  concerned  with  another  important  task  of  digraph 
analysis:  cycle  detection,  enumeration,  and  elimination.  All  cycles  in  the 
digraph  are  first  identified.  In  a given  cycle,  if  there  exists  an  edge 
which  has  a priority  other  than  the  highest  (i.e.,  priority  1),  then  the 
system  proceeds  to  eliminate  the  cycle  by  deleting  an  edge  which  has  lowest 
priority.  Otherwise,  the  cycle  is  unbreakable;  hence  the  user  is  provided 
with  an  error  message  Indicating  the  Illegal  circular  definitions. 

Algorithm  6.5  of  Section  6.3.4  precisely  performs  these  functions. 

In  the  course  of  cycle  analysis,  a path  matrix  (or  reachability  matrix) 
is  created  from  the  adjacency  matrix  A.  This  is  accomplished  by  using  the 
Warshall's  algorithm  (i.e.,  Algorithm  6.4)  as  presented  in  Section  6.3.4. 

After  the  path  matrix  P has  been  generated,  its  diagonal  is  examined  to 
determine  the  existence  of  any  cycles  in  the  digraph.  If  the  diagonal  has 
all  zero  entries,  then  there  are  no  cycles  in  the  digraph  and  the  Processor 
proceeds  to  the  next  subphase  of  sequence  determination.  On  the  other  hand, 
if  there  exists  at  least  one  non-zero  entry  in  the  diagonal.  It  means  there 
are  some  cycles  in  the  digraph.  Then  Algorithm  6.5  identifies  and  enumerates 
distinct  cycles  and  tries  to  eliminate  them  automatically,  if  possible 
(see  Section  6.3.4  for  more  details). 

At  this  stage,  the  Processor  completes  the  phase  of  graph  analysis.  If 
any  logical  errors  (such  as  inconsistencies,  incompleteness,  ambiguities,  and 
Illegal  cycles)  have  been  detected,  then  appropriate  messages  together  with 
various  reports  would  have  been  provided  to  the  user  for  the  purposes  of 
Identifying  the  causes  of  the  problems,  possibly  with  suggestions  for  cor- 
rection. In  this  case,  the  Processor  stops  here.  Otherwise,  the  Processor 
proceeds  to  next  subphase  of  Inter-test-module  sequence  determination. 
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6.4.5  INTER-TEST-MODULE  SEQUENCE  DETERMINATION 

This  subphase  further  analyzes  the  cycle-free 
digraph  of  the  NOPAL  test  specification  to  determine 
the  sequences  of  events  in  the  whole  NOPAL  specification 
based  on  precedence  relationships. 

Section  6.3.5  describes  this  process  of  sequence 

determination  in  more  details.  Basically  the  sequencing 
algorithm  (e.g.,  Algorithm  6.7)  takes  the  adjacency 

matrix  of  the  digraph  to  rank  the  nodes  according  to 

their  precedence  relationships  and  then  to  reorder  the 

nodes  based  on  their  rank.  The  output  of  this  process 

is  an  "order  vector"  ORDER,  such  that  ORDER(i)  is  the 

node  number  which  will  be  executed  at  step  i. 

Shown  in  Figure  6.10  are  the  order  vector  and  the 
rank  sets  resulting  from  an  application  of  Algorithm  6.7 
to  the  adjacency  matrix  of  Figure  6.2  (which  in  turn 
corresponds  to  the  sample  NOPAL  specification  MINIRADIO- 
SET of  Figure  3.2).  Note  that  the  algorithm  generates 
only  one  of  the  possible  sequences  of  nodes,  due  to  the 
fact  that  nodes  of  the  same  rank  level  can  occur  in 
any  order,  or  in  parallel. 

This  sequence  of  nodes  is  used  in  the  next  phase 
of  code  generation  for  the  invocation  of  test  modules 
and  for  inserting  proper  control  logic. 

After  both  the  intra-test-module  and  inter-test- 
module  analysis  and  sequencing  have  been  done  success- 
fully, the  Processor  proceeds  to  next  major  phase  of 
code  generation. 
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ORDER 


VECTOR 

INDEX 

ORDER 

VECTOR 

RANK 

NAME 

TYPE 

1 

1 

0 

DC-INPUT 

TEST  MODULE 

2 

7 

1 

D2 

DIAGNOSIS 

3 

8 

1 

D3 

DIAGNOSIS 

4 

5 

2 

FREQ 

TEST  MODULE 

5 

9 

3 

D4 

DIAGNOSIS 

6 

10 

3 

D5 

DIAGNOSIS 

7 

11 

3 

D6 

DIAGNOSIS 

8 

20 

3 

VI 

VARIABLE 

9 

2 

4 

AMPL 

TEST  MODULE 

10 

12 

5 

D7 

DIAGNOSIS 

11 

13 

5 

D8 

DIAGNOSIS 

12 

3 

5 

DISTORT  2W 

TEST  MODULE 

13 

4 

5 

DISTORT  VOLT 

TEST  MODULE 

14 

19 

6 

30 

DIAGNOSIS 

15 

14 

6 

24 

DIAGNOSIS 

16 

15 

6 

25 

DIAGNOSIS 

17 

16 

6 

26 

DIAGNOSIS 

18 

6 

7 

DISTORT  lOMW 

TEST  MODULE 

19 

17 

8 

27 

DIAGNOSIS 

20 

18 

8 

28 

DIAGNOSIS 

FIGURE  6.10  SEQUENCED  NODES  OF  DIGRAPH  FOR 

THE  SAMPLE  PROBLEM  OF  FIGURE  3.2 


286 


CHAPTER  7 


CODE  GENERATION 

7.1  Introduction  and  Overview 

As  shown  in  Figure  7.1  this  code  generation  phase 
of  the  NOPAL  Processor  accepts  as  input  the  digraph  re- 
presented by  the  weighted  adjacency  matrix,  the  sequence 
of  nodes  represented  by  an  order  vector,  and  the  storage 
entries  in  the  simulated  associative  memory,  and  produces 
as  output  a complete  object  program  in  OPAL. 

To  some  extent^  the  order  vector  which  was  generated 
during  the  last  phase  of  analysis  and  sequencing  provides 
a skeleton  for  the  object  test  program  because  it  identi- 
fies each  node  of  the  digraph  in  the  order  that  the  cor- 
responding event  is  supposed  to  be  executed.  In  order  to 
generate  complete  object  code,  more  information  about  each 
node  is  needed  to  be  extracted  from  the  simulated  asso- 
ciative memory. 

As  indicated  in  Figure  6.4  of  System  Flowchart  for 
Specification  Analysis  and  Sequencing,  and  Code  Generation, 
the  process  of  code , generation  is  initiated  immediately 
after  the  ohase  of  sequence  determination.  For  each  test 
module,  an  intra-test  code  generation  process  is  begun 
once  to  generate  a procedure  right  after  the  intra-test 
analysis  and  sequencing.  Once  the  inter-test  analysis  and 
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Figure  7.1 


Overview  of  Code  Generation 


sequencing  is  done,  the  inter-test  code  generation  process 
is  started  to  generate  a test  monitor  (main  procedure) 
which  includes  defining  global  and  systems  variables,  de- 
fining procedures  for  messages,  invoking  test-module  pro- 
cedures, and  inserting  control  logic.  The  steps  of  code 
generation  are  summarized  in  Table  7.1.  Capitalized  names 
enclosed  in  parentheses  are  procedures  to  be  invoked.  Note 
that  these  steps  are  general,  hence  they  should  be  still 
applicable  even  if  the  object  test  program  v/ere  not  in 
OPAL. 

In  order  to  facilitate  the  illustration  of  the  code 
generation  process  in  the  subsequent  sections,  a procedure 
(subroutine)  EMIT  with  one  argument  of  character  string 
is  defined  as  to  output  a string  of  text  to  an  output 
medium.  For  example,  in  terms  of  PL/1  language,  it  can  be 
implemented  as  follows: 

EMIT:  PROCEDURE  (TEXT);  /*  STREAM-ORIENTED  */ 

/*  OUTPUT  "TEXT"  to  output  medium  "OUTFILE"  */ 

DCL  TEXT  CHAR(*) ; 

' 

DCL  OUTFILE  FILE  STREAM  OUTPUT; 

PUT  FILE  (OUTFILE)  EDIT  (TEXT)  (A); 

END  EMIT; 
or 
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TABLE  7.1  STEPS  OF  CODE  GENERATION  PHASE  OF  NOPAL  PROCESSOR 


A.  For  each  test  module,  define  a procedure 
(GENTEST) . 

B.  Generate  a test  monitor,  i.e.,  main  procedure: 

i'  - 

I 1.  Define  procedure  header. 

1 • 2.  Declare  and  initialize  global  variables  and 

systems  variables. 

j 3.  For  each  message  defined  in  the  NOPAL 

I 

I specification,  define  a procedure  (GENMSG). 

[ 4.  Based  on  the  order  vector  for  the  NOPAL 

specification,  generate  a sequence  of  test- 
module  procedure  calls  and  properly  insert 
control  logic  ( INVOKE_TEST ) . 

5.  End  the  procedure. 

C.  Merge  the  user-supplied  ATE-function  definitions 
coded  in  object  language,  if  any. 


EMIT:  PROCEDURE  (TEXT);  /*  RE CORD_or ien t ed  */ 

/*  Output  "TEXT"  to  output  medium  "OUTFILF,"  */ 

DCL  TEXT  CHAR(*) ; 

DCL  OUTFILE  FILE  RECORD  OUTPUT; 

DCL  OUTREC  CHAR  (MAX_OUTFI LE_RECO RD_S I ZE ) 

BASED  (P)  ; 

LOCATE  OUTREC  FILE (OUTFILE) ; 

OUTREC  = TEXT; 

END  EMIT; 

In  other  words,  if  a piece  of  object  code,  TEXT,  is 
to  be  generated  during  the  process  of  code  generation, 
then  it  is  achieved  by  an  invocation  of  the  EMIT  procedure, 
"CALL  EMIT (TEXT) ;" . Also  note  that  a concatenation 
operator  (| |)  is  frequently  used  to  concatenate  a sub- 
string with  another  in  the  subsequent  code  generation 
algorithms.  For  instance,  "CALL  EMIT  (TEXTl  ||  TEXT2);" 
means  emit  a piece  of  code  which  consists  of  two  character 
strings,  TEXTl  and  TEXT2 , concatenated  in  that  order. 

The  following  sections  describe  in  more  detail  the 
subphases  of  code  generation.  In  the  subsequent  discussions 
the  object  language  OPAL  is  assumed.  Section  7.2  deals 
with  the  intra-test-module  code  generation  for  a given  test 
module.  Section  7.3  is  concerned  with  the  inter-test- 
module  code  generation  for  the  whole  NOPAL  specification. 
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Section  7.4  presents  the  capability  of  incorporating 
user-supplied  ATE  functions  written  in  object  language. 
7.2  INTRA-TEST-MODULE  CODE  GENERATION 

This  subphase  is  concerned  with  the  internal  code 
generation  for  a test  module.  It  is  initiated  once  for 
each  test  module,  after  the  intra-test-module  analysis 
and  sequencing  is  done.  Basically,  a procedure  (sub- 
routine) is  generated  for  each  test  module  defined  in 
the  NOPAL  specification.  Algorithms  7.1  to  7.3  give 
the  steps  of  code  generation  for  a given  test  module. 

Algorithm  7.1  starts  with  determination  of  the 
dimensions  and  bounds  of  all  global,  TARGET,  subscripted 
variables  which  are  defined  in  this  test  module.  The 
number  of  dimensions  of  a subscripted  variable  can  be 
easily  determined  by  checking  its  number  of  subscripts. 

In  current  version  of  NOPAL,  the  lower  bound  of  any 
dimension  in  an  array  variable  is  always  assumed  to  be  1. 
As  for  the  upper  bounds,  they  can  be  determined  by  exam- 
ining all  the  occurrences  of  the  respective  subscript 
expressions.  The  maximum  possible  value  in  a given 
dimension  will  be  the  upper  bound  for  that  dimension. 
Algorithm  7.1  then  generates  code  for  a subroutine  header 
and  for  any  local  variable  declarations  (Steps  S2  & S3). 
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ALGORITHM  7.1  CODE  GENERATION  FOR  A TEST  MODULE,  t 
SO:  /*  Initialize  counter  for  iterative  control 

functions  */ 

Set  //LOOPS  - 0; 

Set  ENDS  • ' . /*  $ ■ OPAL  stmnt  end  marker  */ 

SI:  Determine  dimension  and  bounds  for  each  global 

TARGET  variable  defined  in  this  test  module  t. 

S2:  Generate  code  for  subroutine  (procedure)  header 

of  test  module  t,  e.g. 

CALL  EMIT  ('DEFINE  SUBROUTINE  'll  tes t-label  ( t ) M 
ENDS)  ; 

S3:  Generate  declarations  for  all  local  variables  in  the 

test  modules  t,  if  any. 

S4:  Declare  a local  system  flag,  e.g. 

CALL  EMIT  ('DECLARE  SYSFLAG  BOOLEAN  INITIAL 
(TRUE)  ' 1 1 
ENDS)  ; 

S5:  Start  test  timing,  e.g. 

CALL  EMIT  ('START  SYSTIME$'); 

S6:  Issue  0-timing  diagnoses,  if  any,  e.g. 

S6.1:  For  each  diagnosis  d in  the  best  module  t, 

perform  step  S6.2. 

S6.2:  If  the  corresponding  logical  operator  • '*' 

and  timing  (d)  ■ 0 then 

CALL  POSTDIAG(d);  /*  issue  diag.  */ 

S7:  Generate  code  for  waveforms  , e.g. 
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S7.1:  Let  n be  the  total  number  of  entities,  and  ORKR  be 

the  order  vector  determined  in  the  phase  of  intra- test- 
module  analysis  and  sequencing. 

S7.2;  For  i = 1 to  n,  perform  step  S7.3. 

S7.3:  If  ORDER(i)  represents  a node  of  waveform  w, 

CALL  GENWAVECw) ; /*  code  for  w */ 

S8:  Generate  code  for  issuing  non- zero- timing  diagnoses  with  proper 

control  logic,  e.g. 

S8.1:  For  each  diagnosis  d in  the  best  module  t,  perform  steps 

S8.2  to  S8.9. 

S8.2:  Let  op  be  the  corresponding  logical  operator. 
S8.3:  If  op  = and  timing  (d)  > 0,  then 
CALL  POSTDIAG(d) . 

S8.4:  If  op  = then  /*  OR  */ 

Call  EMIT('IF  SYSFLAG  THEN');  and 
CALL  POSTDIAG(d). 

S8.5:  If  op  = ' h'  then  /*  OR-NOT  */ 

CALL  EMITCIF  NOT  SYSFLAG  THEN')  ; 
and  CALL  POSTDIAG  (d). 

S8.6:  If  op  = '8'  then  /*  AND  V 

CALL  EMITCIF  SYSFLAG  THEN’); 
and  go  to  S8.9. 

S8.7;  If  op  » '5-»'  then  /*  AND-NOT  */ 

CALL  EMITCIF  NOT  SYSFLAG  THEN  ') ; 
and  go  to  S 8 . 9 . 
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S8.8: 


go  to  S8.1. 

S8.9:  Call  EMITC'SET  NO_TESTS_IN_CONJCd) 

= NO_TESTS_IN_CONJ(d)-l  $'); 

Call  EMITCIF  NO_TESTS_IN_CONJ(d)  = 0 
THEN  '); 

CALL  POSTDIAG(d) ; 

CALL  EMITC’END  IF$'). 

S9;  If  there  are  iterative  control  functions  (STEPJDF  or  LISTJDF) 
in  the  test  modiale,  then  generate  code  for  closing  the  loops 
properly,  e.g. 

S9.1:  For  i = 1 to  #LOOPS,  perform  step  S9.2. 

S9.2:  CALL  EMIT (’ENDS') ; 

SIO:  Set  the  test-module  flag  to  "tested",  e.g. 

Let  i be  the  node  number  for  test  module  t; 

CALL  EMITC'SET  TEST_FLAG('  ||  i ||  ')  = TESTED$')  ; 

Sll:  Generate  code  for  closing  the  subroutine  for  test  module  t, 
e.g. 

CALL  EMIT  ('END'  ||  test_label(t)  j]  ENDS); 

SI 2:  Return. 
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ALGORIT™  7.2  POSTDIAGCd):  PR(X:EDURE  FOR  ISSUING  A DIAGNOSIS 
SI;  Set  k = 0.  /*  counter  for  affected  components  */ 

S2:  If  there  are  no  affected  conponents  in  the  diagnosis  d,  then 

go  to  S6. 

S3:  Save  affected  conponents  in  system  area  "SYSCOMP",  e.g. 

For  i=l  to  #COMPS,  perform  step  S3.1.  i 

S3.1:  Call  EMITC'SET  SYSCCMPC  II  i II  ' || 

FAIL_m(i)  II  '('  II  C0MP_ID(i)  ||  $'); 

S4:  Set  k » #C0MPS. 

S5:  Save  operator  ("and"  or  "or")  in  affected  conponents,  e.g. 

If  ANDJDR  = ’5’  then  CALL  EMIT('SET  SYSOP  = "AND"  $'); 
else  call  EMIT  ('SET  SYSOP  = "OR  "$’). 

S6:  Save  actual  number  of  affected  conponents,  e.g. 

Call  EMITC'SET  NO_COMPS  = ' ||  k ||  ENDS); 

S7:  Set  k=0.  /*  counter  for  other  parameters  */ 

S8:  If  other- parameters  field  is  null  then  go  to  Sll. 

S9:  Save  other  parameters  in  system  area  "SYSPARM",  e.g.  | 

For  i=l  to  #PARMS,  perform  step  S9.1. 

S9.1:  Call  EMITC'SET  SYSPARM('  1|  i ||  ')  = ' II 

PARM(i)  II  ')  $•  );  ^ 

SIO:  Set  k = #PARMS. 

Sll:  Save  actual  number  of  other  parameters,  e.g. 

Call  EMITC'SET  NO_PARMS  - ’ ||  k ||  ENDS); 

S12;  If  message  type  is  null,  then  go  to  S15. 

S13:  If  TIMING  field  is  not  null  or  zero,  then  delay  issuance 
of  message,  e.g. 
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Call  EMIT  (’DELAY  UNTIL  SYSTIME  >=  ' || 

TIMING  II  ENDS); 

S14;  Issue  the  message  by  call  the  corresponding  message 
reutine;  e.g., 

Call  EMIT  (’CALL  ’ ||  OP_MSG.TYPE  ||  ENDS); 

S13:  If  there  is  no  operator  variable  input,  then  go  to  S17. 

S16:  Issue  comnand  to  get  input  from  console;  e.g.  call 

EMIT  ('INPUT  FROM  CONSOLE  ' ||  OP_RPS. VAR(l)) ; 

S16.1:  Fbr  i=2  to  total-number-of- input- variables, 

Call  EMIT  (','  II  OP_RPS.VAR  (i)); 

S16.2:  Call  EMIT  (ENDS); 

S17:  If  Y/N  operator  response  is  expected,  then  wait  until  operator's 

manual  intervention,  e.g.  Call  EMIT(' DELAY  UNTIL  MANUAL  INTER- 
VENTIONS) ; 

/*  In  this  case,  a system  variable  SYSY_N  is  assumed  to  be  set 
to  'Y'  or  'N'  afterwards  */ 

S18:  Set  the  diagnosis  flag  to  "SELECTED",  e.g. 

Let  i be  the  node  number  for  the  diagnosis  d; 

Call  EMIT  ('SET  DIAG_FLAG  ('  ||  i ||  ')  = SELECTEDS'); 

S19:  Return. 


ALGORITHM  7.3  GENWAVE(w) : PROCEDURE  TO  GENERATE  CODE  FOR  A WAVEFORM 


SI:  If  w is  null  then  go  to  S24. 

S2:  If  w is  a sinple  conjunction  or  assertion,  then  call  SIMPLE (w) ; 

and  then  go  to  S24. 

S3:  /*  conditiOTial  */ 

Generate  if_clause,  e.g. 

call  EMITC’IF  * ||  CONDITICN(w)  ||  'THEN'); 

S3.1:  /*  True-part:  Simple  */ 

Call  SIMPLE (TRUE_PAKr(w)); 

S3. 2:  /*  Trace  through  false-part  */ 

Set  w = FALSE_PART(w) ; 

S3. 3:  If  w is  not  null,  then 

call  EMIT('ELSE'); 

S3. 4:  go  to  SI. 

S4:  /*  Steps  S4  through  S23  define  the  internal  procedure 

SIMPLE  (w).  */ 

Let  TEMP  be  push- down  stack  of  character  strings,  e.g.  DCL 
TEMP  (255)  VARYING  CONTROLLED; 

Set  #V  » 0.  /*  counter  */ 

S5:  If  w is  an  assertion,  then  go  to  Sll. 

S6:  /*  case  of  conjunction:  steps  S6-S10.2  V 

For  each  triplet  in  the  conjunction,  perform  steps  S7  to  S10.2. 
S7:  Save  UUT  connection  points  in  system  area,  e.g.  call  EMIT 

('SET  N0_PINS  » ' II  #PTS  j)  ENDS); 

S7.1:  For  i = 1 to  #PTS, 
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Call  EMITC’Set  SYSPINS(' 


M = ' 


POINT. ID(i)  II  ENDS); 

S8:  /*  If  an  argument  in  the  function  is  of  the  form* 

< relational_op  > < arith_expr  > [ < dimension  > ] 

then  replace  the  argument  by  a system  A^riable  X 
and  add  a new  pseudo  assertion: 

X < relational_op  > < arith_expr  > */ 

For  each  argument  arg  in  the  function,  perform 
steps  S8.1  to  8,4. 

S8.1:  If  arg  is  not  of  the  form: 

< relational_op  > < arith_expr  > [ < dimension  > ] , 

then  go  to  S8. 

S8.2:  Set  #V  = #V  + 1. 

S8.3:  Replace  the  argument  with  a system  variable,  retaining 

the  dimension;  e.g. 

Set  arg  = 'SYS_V'  ||  #V[  ||  < dimension  > ]. 

S8.4:  Push  a new  pseudo  assertion  to  the  stack  TEMP;  e.g. 

Allocate  TEMP,  and  set  TEMP  = 'SYS_V'  | | #V  1 1 

< Relational_op  > |1  < arith_expr  >. 

S9:  Invoke  the  ATE  function;  e.g. 

Call  EMIT ('CALL'  ||  FUNC_DIM_EX  ||  ENDS); 

SIO:  Generate  code  for  those  new  pseudo  assertions  in  the  stack 

TEMP,  if  any,  e.g. 

While  stack  TEMP  is  not  empty,  perform  steps  SlO.l  to  SIO. 2, 
SlO.l:  Call  EMITC'SET  SYSFLAG  = SYSFLAG8' 

I I TB1P  I I ENDS) ; 
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S10.2:  Pop  the  slack  TEMP,  e.g. 

Free  TEMP; 

Sll:  /*  Case  of  assertions:  Steps  Sll  to  S22.3  */ 

If  w involves  control  function,  then  go  to  S17. 

S12:  /*  regular  assertion  */ 

If  there  is  no  TARGET  variable  in  the  assertion,  then  go  to 
S14. 

SI 3;  /*  assertion  with  a TARGET  variable  */ 

Generate  an  assignment  statement,  e.g. 

Call  EMITC'SET'  ||  w K ENDS); 

Go  to  S23. 

S14:  /*  assertion  having  no  TARGET  variable  */ 

If  the  assertion  involves  a ''range",  i.e.,  of  the  form: 

expl  = exp2  +-  exp3  [I] 
then  go  to  S16. 

SIS:  /*  Simple  assertion  without  range; 

AND  with  SYSFLAG  for  decision  */ 

CALL  EMITC'SET  SYSFLAG  = SYSFLAG  § ' |j  || 

ENDS); 

go  to  S23. 

S16:  /*  assertion  with  range; 

expand  it  into  two  equivalent  assertions: 
ej^  <*  e^  + 03  [*02/100] , 

e^  >=  62  - 03  [*02/100].  */ 

Set  TEMP  = exp3. 
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S16.1:  If  percent  C%)  appears  in  the  range,  then  treat 

% 

exp3  as  percentage  of  exp2,  e.g.  Set  TEMP  = TEMP  * 
exp2/100.  I 

S16.2:  Call  EMIT('SET  SYSFIAG  = SYSFIAG  i | | 

expl  II  '<=  ' II  exp2  ||  ' + ' ||  TEMP  ||  ENDS); 

S16.3:  Call  ENDTC'SET  SYSFLAG  = SYSFIAG  5' 

1 I expl  II  ' > ='  I 1 exp2  | | | | TEMP  | | j 

ENDS) ; 

S16.4:  go  to  S23.  j 

SI 7:  /*  Control  functions:  as  of  now, 

STEP_OF  or  LIST_OF  */ 

j 

Let  "cv  = func_id  (el,  e2,  en)"  be  the  assertion; 
and  n be  the  number  of  arguments  in  the  function  . 

SIS:  If  func_id  = 'STEPJDF'  then  go  to  S21. 

S19:  If  func_id  = ’LISTJDF’  then  go  to  S22. 

S20:  /*  In  error,  unless  new  control  functions  is  to  be  introduced 

in  the  future  */ 

go  to  S12.  /*  default:  treated  as  regular  */ 

I 

S21:  I*  Control  function  STEPjDF  */ 

Generate  code  for  iteration  by  step  and  increment,  e.g.  Call  j 

EMITC’REPEAT  FOR  ' | | cv  | | ' = ' | I 

el  I I 'TO'  I I e2  I I 'BY'  ||  e3  ||  ENDS);  Go  to  S23. 

S22:  /*Control  function  : LISTJDF  */ 

Generate  code  for  iteration  by  a list  of  elements,  e.g.  \ 

call  EMIT  ('REPEAT  FOR  ' | | cv  | | ' ='  ) ; 
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S22.1:  For  i=l  to  n,  perform  steps  S22.2  to  S22.3. 
S22.2:  If  i-th  element  ei  is  of  the  form: 
STEP_OF  (a,b,c) 

then  call  EMIT(a  ||  ' TO'  ||  b H 'BY'  [j  c) ; 
else  call  EMIT(ei) ; 

S22.3:  If  i=n  then  /*  last  element  */ 
call  EMIT (ENDS) ; 

ELSE  call  EMITC  ,') ; 

S23:  Return.  /*  end  of  procedure  SIMPLE  */ 


A run-time  local  system  flag  (SYSFLAG),  which  will  contain 
the  TRUE/FALSE  result  of  the  test  module  after  execution, 
is  initialized  (step  S4)  and  will  be  properly  altered 
later.  The  algorithm  then  starts  the  test  timing,  and 
selects  all  diagnoses  which  are  associated  with  logical 
operator  * (don't-care)  and  with  zero  timing  (steps  S5 
to  S6.2).  Next  it  generates  code  for  conjunctions  and 
assertions  by  calling  GENWAVE  (Algorithm  7.3),  in  the 
order  specified  by  the  order  vector  (which  is  a product 
of  last  sequencing  stage)  (steps  S7  to  S7.3).  Then  the 
algorithm  continues  to  generate  code  for  selecting  non- 
zero-timing diagnoses  with  proper  run-time  control  logic 
(steps  S8  to  S8.9).  The  control  logic  is  primarily  con- 
veyed by  the  test-result  flag  (SYSFLAG)  and  varies  accord- 
ing to  different  logical  operators.  Finally  it  closes 
the  loops  for  iterative  control  functions,  if  any,  sets 
the  test  flag,  and  closes  the  subroutine  definition  for 
the  test  module  (steps  S9  to  Sll) . 

Algorithm  7.2  is  a supporting  routine  (POSTDIAG) 
for  Algorithm  7.1.  It  is  invoked  whenever  a diagnosis  is 
ready  to  be  posted.  The  algorithm  first  saves  the  affect- 
ed components  (steps  S2  to  S7)  and  other  parameters 
(steps  S7  to  Sll)  in  some  system  areas,  so  that  these  are 
accessible  in  the  message  routine  (to  be  discussed  in 
next  section).  Next,  the  message  is  issued  with  proper 
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time  delay  (steps  S13  and  S14).  Note  that  each  message 
(identified  by  "type")  will  be  defined  as  a sub-routine, 
hence  is  invoked  by  a subroutine  call.  The  algorithm 
proceeds  to  generate  code  for  possible  operator  response 
and  input  variables  (steps  S15  to  S18).  Finally  it  sets 
the  diagnosis  flag  to  "selected"  (step  S18). 

Algorithm  7.3  is  another  supporting  routine  (GENWAVE) 
for  algorithm  7.1.  It  is  called  whenever  a waveform 
(conjunction  or  assertion)  in  a test  module  is  due  for 
code  generation.  The  algorithm  generates  code  for  a 
simple  conjunction  or  assertion  by  calling  an  internal 
routine  SIMPLE  (steps  S2  and  S3.1).  It  also  takes  care 
of  conditional  waveforms  (steps  S3  to  S3. 4).  The  internal 
procedure  SIMPLE  (steps  S4  to  S23)  generates  code  for  a 
simple  conjunction  or  assertion.  In  the  case  of  conjunc- 
tion, the  procedure  first  saves  the  UUT  connection  points 
(steps  S7  and  S7.1).  If  an  argument  in  a function-dimension- 
expression  is  of  the  form:  < relatlonal_operator  > 

< arithmetic_expression  >,  then  the  argument  is  replaced 
by  a new  variable  X,  and  a new  assertion  of  the  form: 

X < relational_operator  > < arithmetic_expression  > is 

to  be  added  (steps  S8  to  S8.4).  Then  the  stimuli  or  mea- 
surement function  is  invoked  with  proper  arguments  (step 
S9),  and  the  code  for  new  assertions,  if  any,  is  generated 


(steps  SIO  to  S10.2).  In  the  case  of  simple  assertion, 
the  procedure  checks  if  the  assertion  has  a TARGET  vari- 
able. An  assignment  statement  is  generated  for  an 
assertion  which  has  a TARGET  variable  (step  S13).  Other- 
wise, if  the  assertion  involves  a range  specification, 
i.e.,  of  the  form; 

exprl  “ expr2  +-  expr3  [Z]  ; 

the  assertion  is  expanded  into  two  equivalent  assertions 
(steps  S16  to  S16.4): 

exprl  < = expr2  + expr3  [ *expr 2 / 100 ] ; 
and 

exprl  >*  expr2  - expr3  [ *expr 2 / 100  ] ; 

Finally,  if  the  assertion  is  one  of  the  following  two 
control  functions: 

X“  STEP_0F  (initial,  upper-bound,  increment); 
or 

X = LIST_0F  (exprl,  expr2,  ...,  exprn)  ; 
then  proper  iteration  control  logics  are  generated  (steps 
S17  to  S22.3). 

After  this  subphase  is  completed  a test  module  sub- 
routine is  generated  corresponding  to  each  test  module 
in  the  NOPAL  specification. 

7.3  Inter- tes t-module  Code  Generation 

This  section  is  concerned  with  overall  inter-test- 
module  code  generation  as  outlined  in  step  B of  Table  7.1. 
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Basically,  it  defines  a "test  monitor"  main  procedure 
which  declares  and  initializes  global/systems  variables, 
def ines message  routines,  and  generates  a sequence  of 
test-module  procedure  calls  with  proper  control  logic 
inserted  based  on  the  order  vector  of  the  NOPAL  speci- 
fication. 

Algorithms  7.4  through  7.7  give  the  steps  of  code 
generation  iu  this  subphase.  Algorithms  7.5  to  7.7  are 
subroutines  which  are  invoked  by  Algorithm  7.4. 

Algorithm  7.4  essentially  defines  a main  program 
which  will  perform  the  tests  described  in  NOPAL  specifi- 
cation. It  begins  with  the  generation  of  main  program 
header.  Then  it  generates  declarations  for  global 
variables  and  systems  variables,  possibly  with  initiali- 
zations (steps  S2  and  S2.1).  Next  it  defines  a message 
subroutine  for  each  message  defined  in  the  NOPAL  speci- 
fication (step  S3).  The  algorithm  proceeds  to  generate 
a sequence  of  test-module  procedure  calls  with  control 
logic  properly  inserted,  based  on  the  order  vector  pro- 
duced in  the  inter-test-module  sequencing  phase  (steps 
S4  and  S4.1).  Note  that  a subroutine  (procedure)  has  been 
generated  corresponding  to  each  test  module  in  the  intra- 
test-module  code  generation  phase  (Section  7.2).  Finally 
it  closes  the  main  program. 


\] 

!3 
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ALGORITHM  7.4  CODE  GENERATION  OF  TEST  MONITOR  FOR  NOPAL  SPECIFICATION 


i: 

\ 

} 

f 

f 

f 


Define  object  program  main  procedure  header,  e.g.  call  EMIT 
('BEGIN  OPAL  PROGRAM  ' H specjiame  |1 
Declare  global  variables,  if  any. 

S2.1:  Declares  and  initialize  systems  variables;  e.g., 

Call  INITIAL;  /*  Algorithm  7.5  */ 

For  each  message  defined  in  the  NOPAL  specification,  define  a 
message  subroutine,  e.g.. 

For  each  message  m defined  in  the  NOPAL  specification,  call 
GENMSG(m) ; /*  Algorithm  7.6  */ 

Generate  a sequence  of  test-module  procedure  calls  and  insert 
proper  control  logics,  e.g.  Let  ORDER  be  the  order  vector 
generated  in  the  phase  of  inter-test-module  sequencing; 

For  each  entry  i in  the  order  vector  ORDER,  perform  step  S4.1. 
S4.1:  If  i corresponds  to  a test  modiile  t,  then  call 

INVOKEJTESTCtj.  /*  Algorithm  7.7  */ 

Close  the  main  procedure,  e.g. 

Call  EMIT  ('END  OPAL  PROGRAM'  |1  specjiame  1|  '$'). 


SI: 


S2: 


S3: 


S4; 


S5; 


ALGORITHM  7.5  INITIAL:  DECLARE  AND  INITIALIZE  SYSTEMS  VARIABLES 
SI:  Declare  an  array,  DIAG_FLAG,  of  diagnosis  flags,  and  initialize 

it,  e.g. 

Call  EMITC DECLARE  DIAG_FLAG  BITSTRING(2) 

ARRAY  (’ll  ^diagnoses  ||')  INITIAL  ("  00  ")  $'); 

S2:  Declare  an  integer  array  NO_TESTS_IN_CCWJ,  for  diagnoses,  and 
initialize  it  to  all  zero,  e.g. 

Call  EMITC DECLARE  NO_TESTS_IN_CONJ  INTEGER 

ARRAY  ('ll  ^diagnoses  ||')  INITLAL  (o)  $ '); 

S5:  Properly  initialize  NO_TEST_IN_CCNJ(d)  of  each  diagnosis  d to 

the  number  of  test  modules  which  are  in  conjuncticn  to  select  the 
diagnosis,  e.g. 

For  each  diagnosis  d,  perform  steps  3.1  to  S3. 3. 

S3.1:  Let  i be  the  node  number  for  diagnosis  d: 

S3. 2:  Let  n be  the  nimber  of  test  modules  in  conjunction  in 
selecting  d. 

S3. 3:  If  n > 0 then 

Call  EMITC'SET  NO_TESTS_IN_CONJC I I 111')='  II  n ||  ’$’) 
S4:  Define  two  flag  constants  SELECTED  and  NOTjSELECTED  for 
d iagno  s es , e.g. 

Call  EMITC  DECLARE  SELECTED  BITSTRING(2) 

INITIALC'IO")  $'); 

Call  EMITC DECLARE  NOT_SELECTED  BITSTRINGC2) 
INITIAL(''01")$')  ; 

S5:  /*  S5  to  S6:  declare/ initialize  variables  for  tests  */ 

Declare  a test  flag  array,  TEST_FLAG,  for  test  modules,  and 
initialize  it,  e.g. 
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Call  EMITC DECLARE  TEST_FLAG  BITSTRING(2) 

ARRAYCll  Hests  M')  INITIAL ("00") $') ; 

S6:  Define  three  flag  constants  NOTJTESTED,  TESTED,  and  SKIPPED 
for  tests,  e.g. 

Call  EMITC DECLARE  NOrjTESTED  BITSTRING(2) 

INITIALC’OO") , TESTED  BITSTRINC(2) 

INITIALC'IO") , SKIPPED  BITSTRING(2) 

INITIAL("01")$') ; 

S7:  /*  Common  area  for  UUT  affected  components  */ 

Declare  an  array  SYSCCM*  and  two  variable  SYSOP  and  NO_CCMPS 
for  passing  affected  components  to  message  routines,  e.g. 

Call  EMITC'DECLARE  SYSCOMP  CHARSTRINGC  | | max#  chars  [ | ') 
ARRAYC  I 1 max#comps  | | ’)  $’)  ; 

Call  BlITC DECLARE  N0_COlPS  INTEGER,  SYSOP  CHARSTRING (3)  S'); 
S8:  /*  Common  area  for  other  parameters  */ 

Declare  an  array  SYSPARM  and  a counter  for  passing  other 
parameters  to  message  routines,  e.g. 

Call  BlITC DECLARE  SYSPARM  CHARSTRING  (’  | | max»chars  1 | ' ) 
ARRAYCll  max#parms  ||  ')$'); 

CALL  EMIT ('DECLARE  NO_PARMS  INTEGER  $'); 

S9:  Declare  an  array  SYSPINS  and  a counter  NO_PINS  for  passing  UUT 
connection  points  to  ATE  stimuli  or  measurement 
Call  EMITC  DECLARE  SYSPINS  CHARSTRINGC  | | max#chars  ||  ') 
ARRAYCll  max#pins  ||  ')  $'); 

SIO:  /*  Miscellaneous  */ 

Declare  a system  flag  SYSFLAG  for  dynamically  invoking  test 
modules,  e.g. 
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Call  EMITC DECLARE  SYSFLAG  BOOLEAN  INITIAL  (TRUE)  $ '); 

SlO.l:  Declare  a system  timer  for  performing  tests,  e.g. 

Call  EMIT(’ DECLARE  SYSTIM  REALS"); 

' SlO.l:  Declare  a system  timer  for  performing  tests, 

e.g.  Call  EMITC’DECLARE  SYSri>E  REALS"); 

S10.2:  Define  a constant  of  blank,  e.g. 

Call  EMIT (’ DECLARE  SYSB  CHARSTRING(l)  INITIAL  ("  ")  S’); 

S10.3:  Define  two  variables  to  contain  number  of  diagnoses 
and  number  of  test  modules,  e.g. 

Call  EMITC’DECLARE  NO_DIAGS,  NOJTESTS  INTEGERS'); 
j.  Call  EMITC’ SET  NO  DLAGS  = ’||  ^Diagnosis  ||  ’S’); 

l:' 

Call  EMITC ’SET  NOJESTS  = 'll  '^test  ||  ’$’); 

S10.4:  Declare  a system  area  SYSY_N  for  Y/N 
operator  response,  e.g. 

CALL  EMIT  (’DECLARE  SYSYJJ  CHARSTRING(l) 

INITIALC"  ")  $ ’); 

Sll:  /*  ORAL  special  feature  in  specifying  UUT  pins  */ 

Specify  UUT  connection  points  in  main  program,  e.g. 

Call  EMITC ’SPECIFY'); 

For  each  UUT  connection  point  p,  perform  steps  Sll.l  to  Sll. 2. 
\ Sll.l:  Call  EMIT  (UUT.  POINT JD(p)); 

; Sll. 2:  If  p is  the  last  UUT  point  in  UUT-connection-points 

1 specification,  then  call  EMITC’S’); 

else  call  EMIT(’,’) ; 

S12 : Return. 
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ALGORITHM  7.6  GENMSG(in):  GENERATE  CODE  FOR  MESSAGE  m 
SI;  Generate  subroutine  header  for  the  message  m,  e.g. 

Call  EMITCDEFINE  SUBROUTINE  '||  m I| 

S2:  Construct  message  text  by  inserting  actual  affected  conponents 

and  other  parameters, 
if  any,  e.g. 

Perform  steps  S3  to  S13. 

S3:  /*  initialization  */ 

Set  ip  = 0; 

Set  is  = 0; 

Set  len  = LENGTH  (text) . 

S4:  /*  Get  next  character  of  text  */ 

Set  is  = is  + 1; 

If  is  > len  then  go  to  S13; 

Set  c = text (is); 

S5:  /*  check  if  c is  one  of  the  3 characters: 

left  parenthesis,  exclamation  mark,  or  single  quote  */ 

If  c = ' ('  then  go  to  S6; 

else  if  c = go  to  S5.1; 

else  if  c - then  go  to  S5.2; 

goto  S2; 

S5.1:  /*  I is  a special  character  in  OPAL; 

Insert  another  '.  (II  denotes  '!')  */ 

Set  text  = SUBSTR(text,  1,  is-1)  || 

II  SUBSTR(text,  is); 

Set  len  = len  +1; 

Set  is  = is  + 1; 

go  to  S2. 
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S5.2:  /*  Single  quote  is  represented  by  " in  NOPAL;  but  by 
in  OPAL.  Hence  change  first  ' to  ! */ 

Set  text  (is)  = ' ! ' ; 

Set  is  = is  + 1; 

I go  to  S2. 

1 't 

S6:  /*  Check  if  (C) , (P) , (Ci) , or  (pp  V 

Set  is  = is  + 1; 
if  is  > len  then  go  to  S13; 

Set  c = text  (is) ; 

If  c = 'C  or  c = 'P'  then  go  to  S7; 

else  go  to  S5- 

S7:  /*  Yes,  (C).  (P),  (Ci),  or  (Pi)  */ 

/*  Output  the  text  before  the  left  parenthesis,  and  advance 
text  pointer  */ 

Call  EMIT(’OUrPUr'  II  SUBSTR  (text,  ip,  is-ip-l))j 
Set  ip  = is  + 1; 

Set  is  = ip; 

If  is  > len  then  go  to  SIO; 

Set  d = text  (is) ; 

If  d is  not  a numeric  digit,  then  go  to  SIO. 

S8 ; Set  jf  * d; 

For  is  = (is+1)  to  len,  perform  steps  S8.1  to  S8.3. 

S8.1:  Set  d “ text (is). 

S8.2:  If  d is  not  a numeric  digit,  then  go  to  S9: 

S8.3:  Set  jf  » jf*10  + d. 

I 

I 

I 


I . 

S9:  Set  js  = jf; 

Set  ip  = is; 
goto  Sll. 

SIO:  /*  CO  or  CP)  V 

If  c = 'O  then  set  jf  *NO_COMPS; 

else  set  jf  = NO_PARMS. 

Sll:  /*  Output  affected  components  and  other  parameters  */ 
If  c = 'C  then  set  temp  = 'SYSCOMP  C' 
else  set  temp  = 'SYSPARM  C'  ; 

Call  EMITC ’OUTPUT’ ) ; 

For  j = js  to  jf,  perform  steps  Sll.l  to  Sll. 2. 

Sll.l:  Call  EMITCtemp  ||  j j|  ’)’); 

S12.2:  If  j = jf  then  call  EMITC’$’); 

else  call  EMITC’,  SYSB,  SYSOP’); 

S12;  If  is  > len  then  go  to  S13; 

Set  c = text  Cis) ; 

If  c = ’)’  then  go  to  S12.1; 

else  go  to  S5. 

S12.1:  Set  ip  = ip+1; 
go  to  S4. 

S13;  /*  Output  remaining  message  text  */ 

If  ip  <=  len,  then 

Call  EMITC ’OUTPUT’  ||  SUBSTR  Ctext,  ip)  |j 
'$'); 

S14:  Close  subroutine  definition,  e.g. 

Call  EMITC’END'  1 1 m 1 1 '$’) ; 

SI 5:  Return. 
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ALGORITHM  7.7  INVOKE_TEST(t) : INVOKE  TEST  MODULE  t 

SI:  /*  Initializations  */ 

Call  EMITC  set  SYSFLAG  - TRUES'); 

Let  i be  the  node  number  for  test  module  t. 

S2:  Generate  control  logic  based  on  predecessor  diagnoses,  e . g.. 

For  each  diagnosis  d,  perform  steps  S2,l  to  S2.6. 

S2.1:  Let  j be  the  node  number  for  diagnosis  d. 

S2.2:  Set  ptyp  « A(j,i);  /*  precedence  type  */ 

S2.3:  If  ptyp  • 0 then  go  to  S2.6 

else  if  ptyp  « 2 or  ptyp  = 5 then  go  to  S2.5. 

S2.4:  /*  d is  related  to  t by  A— i , component 

protection,  or  conjunctive  component  subset  */ 

If  the  diagnosis  has  been  selected,  then 

set  SYSFLAG  to  false,  and  skip  t's  successor,  e.g. 
Call  EMITCSET  SYSFLAG  - SYSFLAG 

AND  DIAG_FLAG( ' I I j M'  ) « NOT_SELECTED$ ' ) ; 

Call  SKIP(t,  ' DIAG_FLAG( ' I I j ||')  = SELECTED'); 

Go  to  S 2 . 6 . 

S2.5:  /*  d is  related  to  t by  A,  or  disjunctive 

component  subset  */ 

If  the  diagnosis  has  not  been  selected,  then 

set  SYSFLAG  to  false,  and  skip  t's  successor,  e.g. 
CALL  EMIT  ('SET  SYSFLAG  - SYSFLAG  and 

DIAG_FLAG  ('||  j ||  ')  - SELECTED$'); 

Call  SKIP(t,  ' DIAG_FLAG( ' I I j ||  ' ) •« 

NOT_SELECTED ' ) ; 

S2.6:  /*  End  of  looping  each  diagnosis  */ 

S3:  If  SYSFLAG  is  true  and  test  module  t has  not  been 

tested  before,  then  emit  code  for  Invoking  the 
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test  module  routine,  e.g.  call  EMIT('IF  SYSFLAG 


THEN  IF  TEST_FLAG  ('  ||  i ||')  = NOT_TESTED 

THEN  CALL  ']|  t e s t_lab e 1 ( t ) || 

S4:  Return. 

S5;  /*  Internal  routine  SKIP(t,  condition):  steps  S5  to  S9,  */ 

/*  If  "condition"  is  true  and  if  t is  not  "skipped"  | 

yet , then  1 


1)  Mark  t as  skipped,  and 

2)  For  each  variable  v solely  defined  in  t,  skip 
recursively  each  successor  test  module  s which 
uses  variables  v as  SOURCE,  by  calling  SKIP 

(s , condition)  */ 

Let  k be  the  node  number  for  test  module  t. 

S6:  Call  EMIT(’IF  TEST_FLAG('  M k 1|’  ) //■= 

SKIPPED  THEN  IF'  I|  condition  ||  'THEN'); 

CALL  EMITCSET  TEST_FLAG('  ||  k || 

' ) - SKIPPED$ ' ) ; 

S7:  For  each  TARGET  variable  v defined  in  t,  perform 

steps  S7.1  to  S7.2. 

S7.1:  If  the  column  for  v in  matrix  A has  exactly 

one  non-zero  entry  (i.e.  v is  uniquely 
defined  as  TARGET  in  t) , then  perform 
step  S7.2,  for  each  test  module  s using  v 
as  SOURCE. 

S7.2:  Call  SKIP  (s,  condition); 

S8:  /*  OPAL  special  constructs;  closing  two  IF's  */ 

Call  EMIT('END$  END$'); 

S9:  Return.  /*  for  the  SKIP  internal  routine  */ 
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Algorithm  7.5  declares  and  initializes  systems 
variables  which  are  used  in  the  generated  object  pro- 
gram. First  it  defines  two  arrays  (DIAG_FLAG  and 
NO_TEST_IN_CONJ ) and  two  flag  constants  (SELECTED  and 
NOT_SELECTED)  for  the  purposes  of  diagnoses  (steps  SI 
to  S4).  NO_TEST_IN_CONJ(i)  initially  contains  the 
number  of  test  modules,  which  are  in  conjunction  in 
selecting  the  diagnosis.  At  execution  time, 

NO_TES T_IN_CON J ( i ) will  be  decremented  once  such  a test 
module  is  executed  and  results  in  true  or  false  (de- 
pending on  the  logical  operator  & or  &— t ) . DIAG_FLAG(i) 
is  set  to  SELECTED  whenever  the  diagnosis  i is  selected. 
The  algorithm  then  defines  an  array  (TEST_FLAG)  and 
three  flag  constants  (NOT_TESTED,  TESTED,  SKIPPED)  for 
the  purposes  of  test  modules  (steps  S5  and  S6). 

TEST_FLAG  is  initialized  to  NOT_TESTED.  At  execution 
time,  TEST_FLAG(i)  for  test  module  i will  be  set  to 
TESTED  once  the  test  module  i is  performed,  or  will  be 
set  to  SKIPPED  once  the  test  module  i is  determined  to 
be  omitted  for  execution.  Then  the  algorithm  proceeds 
to  declare  common  areas  for  the  affected  components 
(SYSCOMP  and  NO_COMPS)  and  other  parameters  (SYSPARM 
and  NO_PARMS)  (steps  S7  and  S8) . These  variables  are 
set  whenever  a diagnosis  is  posted,  and  then  they  are 
used  in  constructing  the  message  text  (see  algorithms 
7.3  and  7.6).  Next,  Algorithm  7.5  defines  two  areas 
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(SYSPINS  and  NO_PINS)  for  passing  UUT  connection  points 
to  ATE  stimuli  or  measurement  functions  (step  S8). 

Thus  SYSPINS  contains  the  set  of  UUT  connection  points, 
and  NO_PINS  gives  the  number  of  these  points,  both  of 
which  are  set  in  a test-module  procedure  and  are 
accessible  when  defining  ATE  stimuli  or  measurement 
functions.  The  algorithm  then  defines  several  mis- 
cellaneous systems  variables  (steps  SIO  to  S10.4). 
Finally  it  generates  a "specify"  statement  to  identify 
all  UUT  test  points  (steps  Sll  to  S11.2),  This  reflects 
the  OPAL  special  requirement  that  UUT  points  must  be 
specified  in  main  program  section  rather  than  in  any 
routine . 

Algorithm  7.6  generates  code  for  a message  defined 
in  NOPAL.  First  it  defines  a subroutine  header.  Then 
it  constructs  the  message  text  by  inserting  affected 
components  and  other  parameters  (steps  S2  to  S13). 
Basically,  if  any  affected  components  (designated  by  (C) 
or  (C^))  have  been  specified  in  the  original  message 
text,  then  they  have  already  been  saved  in  a system 
area  (SYSCOMP);  hence  each  corresponding  affected  com- 
ponent is  available  from  this  area  and  is  properly  in- 
serted in  the  message  text.  Similarly  other  parameters 
have  been  saved  in  another  system  area  (SYSPARM);  hence 

they  are  available  for  insertion  in  the  message  text. 
Finally,  the  algorithm  simply  ends  the  definition  for 

the  message  subroutine. 


3] 


[. 

i 


i 

r 

[ 

1 

I 

t 

\ 

I 


Algorithm  7.7  conditionally  invokes  a test-module 
routine  and  inserts  necessarily  control  logic.  A 

flag  (SYSFLAG)  is  first  initialized  to  true  (step  SI).  ’ 

Then  for  each  predecessor  diagnosis  the  precedence  type 
is  examined  to  generate  proper  control  logic  (steps 
S2  to  S2.6).  If  the  diagnosis  is  related  to  the  test 
module  by  precedence  type  2 (interactiveness  - "A") 
or  5 (fault  Isolation  - disjunctive  component),  and  if 
the  diagnosis  has  not  been  selected,  then  the  flag  is 
set  to  false,  and  the  successors  of  the  test  module  are 
properly  skipped  for  execution  (step  S2.5).  On  the 
other  hand  if  the  precedence  type  is  3 (interactive  - 
"A-t  ")  or  4 (component  protection)  or  6 (fault  isola- 
tion-conjunctive components)  and  if  the  diagnosis  has 
been  selected,  then  the  flag  is  set  to  false  and  the 
successors  of  the  test  module  are  properly  skipped 
(step  S2.4).  Finally,  if  the  flag  is  true  and  the 
test  module  has  not  been  tested  then  the  test-module 
routine  is  invoked  (step  S3).  An  internal  routine  SKIP 
(steps  S5  to  S9)  is  used  to  skip  successors  of  a test 
module  conditionally.  The  condition  is  either  a dia- 
gnosis which  is  selected  or  a diagnosis  which  is  not 
selected.  If  the  test  module  has  already  been  skipped, 
then  the  routine  will  not  proceed  further.  Otherwise^ 
i t recursively  skips  each  descendent  test  module  whichever 
uses  a global  variable  that  is  uniquely  defined  in  the  current 
test  module  (steps  S7  to  S8). 
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In  summary,  these  four  algorithms  together  define 
the  main  program  in  the  object  language,  which  will 
perform  the  tests  as  provided  in  the  NOPAL  test 
specif icat ion. 

7.4  Object  Program  Library  Inclusion 

Usually,  the  definitions  (in  object  language)  for 
all  ATE  functions  (stimuli,  measurement,  and  evaluation) 
will  be  provided  in  the  compile  phase  (some  ev6n  at 
execution  time)  of  the  object  program. 

To  facilitate  the  inclusion  of  object  routines 
(particularly  non-standard  or  special-purpose  routines) 
the  NOPAL  system  provides  the  user  with  an  option  of 
including  his  own  object  library  at  this  stage.  One 
way  of  implementing  it  is  summarized  as  follows: 

If  the  user  wants  to  include  his  own  object  libary, 
then  he  should  put  in  a file,  say,  OBJLIB,  and  provide 
proper  data  definition  for  this  file  (e.g.  a proper  DD 
card  in  IBM  system)  when  invoking  NOPAL  processor.  The 
NOPAL  system  will  check  the  status  of  the  file  OBJLIB. 

If  the  tile  is  undefined  (that  is,  the  user  does  not 
provide  his  object  library),  then  nothing  needs  to  be 
done.  Otherwise,  the  file  will  be  merged  with  the 
object  code  which  has  been  generated  in  both  intra- 
and  inter— test-module  code  generation  phases. 
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CHAPTER  8 


CONCLUSIONS 


This  report  has  described  a theory  and 

a methodology  for  programming  computer  controlled 
Automatic  Test  Equipment.  The  formalism  for  this 
methodology  is  imbedded  in  a non-procedural  specifi- 
cation language,  NOPAL,  in  which  test  specifications 
for  various  classes  of  UUTs  can  be  described.  The 
theory  and  methodology  for  programming  ATE  has  been 
incorporated  in  a software  production  system  (NOPAL 
Processor)  which  generates  reliable  and  efficient  test 
programs  from  test  specifications  expressed  in  NOPAL. 

The  test  programs  are  used  to  analyze  and  isolate  faulty 
components  of  the  UUT  in  an  ATS. 

The  use  of  such  an  automatic  test  program  generation 
system  in  an  ATS  clearly  reduces  the  amount  of  expertise 
and  time  needed  to  produce  test  programs.  Equally 
important  is  its  contribution  to  confidence  in  automatic 
testing.  The  NOPAL  language  is  non-procedural  and 
incremental.  It  enables  the  user  to  describe  test 
modules  in  descriptive  statements  that  may  appear  in  any 
order.  Also  test  modules  can  be  independently  added  or 
modified.  The  Processor  analyzes  the  user's  specification, 
checks  for  completeness  and  consistency,  deduces  sequence  of 
events,  and  finally  produces  a reliable,  complete  test  pro- 
gram. The  user  is  relieved  of  the  procedural  thinking  and 


programming.  Thus  the  need  for  expertise,  the  amount  of  program 
coding  and  debugging  time,  and  the  potential  human  errors  can  be 
much  reduced. 


The  following  conclusions  can  be  drawn  regarding  several 
other  aspects  of  the  NOPAL  system: 

(1)  Man-machine  interface:  The  NOPAL  Processor  provides 
many  reports  to  enable  the  user  to  check  his  specifications. 

The  reports  include:  (a)  a reformatted  specification  listing 

which  reorganizes  the  specification  for  better  readability  and 
assists  the  user  in  understanding  his  test  specification,  (b) 
several  cross  reference  reports  to  provide  the  user  with  a 
picture  of  the  interactions  among  various  components  of  the  test 
specification,  (c)  sequence  flowcharts  of  the  resultant  test 
program,  and  (d)  error  and  warning  messages  to  alert  the  user  to 
inconsistency,  incompleteness,  and  ambiguities  in  his  specifi- 
cation and  to  help  him  pinpoint  the  trouble  spots  for  correction. 

(2)  Knowledge  base:  Two  types  of  knowledge  base  have  been 
incorporated  in  the  NOPAL  system:  engineering  and  computer  pro- 
gramming. The  former  includes  identifying  failure  modes,  assur- 
ing non-destructive  testing,  distinguishing  s t imul i/measuremen t 
waveforms  from  pure  computations,  and  sharing  diagnoses  among 
multiple  test  modules  to  reduce  ambiguity  in  fault  isolation. 

The  latter  includes  the  construction  of  a directed  graph  model 
from  the  test  specification,  the  analysis  of  the  graph,  and  the 
encoding  into  object  test  program. 

(3)  Optimization:  The  test  program  generation  system  auto- 
matically sequences  the  test  modules  and  incorporates  control 

logic  in  the  final  test  program.  The  program  will  dynamically 

321 


schedule  for  execution  only  those  tests  needed  at  test-time. 

The  tests  are  scheduled  in  a top-down  fashion.  The  top  level, 
more  generic  functional  test,  is  first  scheduled  to  discover  as 
many  faults  as  possible.  Only  when  the  UUT  fails  in  such  a 
functional  test,  the  program  proceeds  to  perform  the  lower  level, 
more  specific  fault  isolation  tests.  Several  other  optimization 
methods  have  also  been  used.  One  method  reduces  the  time  con- 
sumed in  application  of  stimuli.  Once  a set  of  stimuli  is  con- 
nected to  the  UUT  points,  as  many  tests  as  possible  are  scheduled 
for  execution.  Another  method  uses  the  idea  that  efficiency  can 
be  obtained  by  first  testing  the  components  which  are  more 
likely  to  fail. 

To  achieve  the  goal  of  total  automation  of  test 
design  and  programming  for  ATE  as  a solution  to  the 
problem  of  high  maintenance  cost,  both  the  test  deter- 
mination and  the  program  production  processes  (top  and 
bottom  parts  of  Figure  1.1)  must  be  automated  and  then 
integrated.  The  automatic  test  determination  process 
for  electronic  circuits  has  been  achieved  independently 
in  the  Moore  School  by  C.  Tinaztepe  [TIN  77].  The  NOPAL 
language  has  been  used  to  describe  complete  test 
specifications.  The  language  has  been  found  to  be  use- 
ful and  adequate. 

Although  some  changes  in  the  object  language  OPAL 
have  been,  and  still  are,  underway,  the  basic  constructs 
remain  unaltered.  In  the  course  of  this  research,  two 
minor,  yet  Important,  modifications  in  OPAL  were  pro- 
posed to  ensure  the  language's  ATE  independence,  One 
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of  them  is  the  capability  of  passing  any  name,  such  as 

resource,  noun,  modifier,  unit,  test  point,  etc. 

(see  Chapter  3)  in  a routine,  or  equivalently  assigning 

any  of  these  items  to  a,  variable.  The  code  generation 

process  has  been  based  upon  this  assumption.  Another 

assumption  is  that  an  OPAL  subroutine  that  corresponds 

to  a NOPAL  stimulus  or  measurement  function  may  include 
a REQUIRE  statement.  This  will  guarantee  that  the 

characteristics  of  the  required  resource  can  be 
specified.  Except  for  these  two  assumptions,  the  NOPAL 
features  have  been  able  to  be  realized  by  the  object 
language  OPAL,  These  additions  to  OPAL  are  believed 
to  be  very  important  in  manual  preparation. 

Some  of  the  tool  and  techniques  that  have  been 
developed  are  very  powerful  and  will  be  generally  use- 
ful to  the  developer  of  programming  systems.  Most 
notable  is  a general  purpose  statement  storage  and 
retrieval  subsystem  that  has  been  developed. 

The  three  major  phases  of  the  NOPAL  Processor  have 
been  fully  designed,  including  various  algorithms  and 
needed  data  structures,  Phase  I,  syntax  and  statement 
analysis,  and  the  in t r a- t es t -modu le  analysis  and 
sequencing  of  phase  II  has  been  successfully  implemented 
in  PL/I(F)  using  an  IBM  370/168  computer.  The  inter- 
test-module analysis  and  sequencing  of  phase  II  has 
been  partially  implemented, 

A number  of  research  directions  may  be  taken  in 


the  future; 
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analysis  and  sequencing,  and  the  code  generation  phases 
of  the  Processor  need  to  be  implemented, 

(2)  Refinements  and  extensions;  An  interactive 
NOPAL  Processor  should  be  a worthwhile  endeavor.  After 
all,  a user  would  typically  go  through  several  iterations 
with  the  NOPAL  system  until  his  problem  is  solved.  An 
interactive  system  would  certainly  make  the  interaction 
between  the  user  and  the  system  more  effective.  The 
two  logical  values,  TRUE  and  FALSE,  should  be  included 
in  the  language.  Currently  a simple  assertion  is 
basically  a relational  expression.  It  would  be  much  more 
flexible  if  a simple  assertion  could  be  extended  to 
include  any  expression  that  yields  a logical  value  TRUE 
or  FALSE.  More  control  functions  should  be  investigated 
to  facilitate  test  modules  composition.  Variables  are 
considered  to  be  of  type  REAL  in  current  system.  Other 
types  such  INTEGER,  STRING,  and  COMPLEX  may  also  be 
needed.  The  combination  of  basic  stimuli  functions  to 
form  a composite  one  needs  to  be  further  studied. 

Whether  the  logic  part  should  be  extended  to  include  the 
selection  of  a diagnosis  based  on  the  other  diagnoses 
needs  further  investigation.  Finally  it  may  be  worth 
making  the  NOPAL  syntax  more  English-like  or  user- 
oriented  . 
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(3)  Other  application  domain;  The  top  part  of 
ATS,  automatic  test  determination,  has  been  based  on  a 
particular  UUT  class  --  electronic  circuits.  In  prin- 
ciple, the  bottom  part,  automatic  test  program 
generation,  can  be  used  in  describing  tests  for 
various  classes  of  UUTs . Other  types  of  UUTs,  such 
as  hydraulic  and  mechanic,  should  be  studied  for  the 
purposes  of  test  determination. 

In  summary  the  NOPAL  language  and  Processor  have 
automated  the  test  program  production  process  for  an 
automatic  test  system.  Although  a lot  of  further 
research  in  this  field  must  be  done  in  the  future, 
this  research  has  made  an  important  step  towards  the 
goal  of  total  automation  of  test  determination  and  test 
program  generation,  hence  has  contributed  to  the 
ultimate  reduction  of  the  skyrocketing  maintenance 
and  support  costs  of  electronics  systems. 
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APPENDIX  A 


NOPAL  SVSTEM  DATA  STRUCTURES 


This  appendix  illustrates  the  data  structures  used  to  encode 


all  of  the  sixteen  types  of  statements  (as  listed  in  Table  5.9  of 
Chapter  5)  in  the  NOPAL  system.  Associated  with  each  type  of  state- 
ment are  two  data  structures:  (1)  storage  entry  and  (2)  actual  data. 
Each  data  structure  is  implemented  by  a PL/1  BASED  structure  IBM  72 
and  is  identified  by  its  main  Ci-e-*  level  1)  structure  name  followed 
by  its  based  pointer  enclosed  in  parentheses.  In  the  drawing,  each 
cell  ("square")  represents  a field  in  the  data  structure.  The  attribute 
of  a field  is  normally  integer  (ie.  FIXED  BINARY)  unless  specified 
otherwise. 
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APPENDIX  B 

AN  EXAMPLE  OF  USING  THE  NOPAL  LANGUAGE  AND  PROCESSOR 


% 

This  appendix  provides  a complete  example  of  the 
• use  of  the  NOPAL  language  and  Processor.  The  sample 

problem  is  the  MINIRADIOSET  test  specification  of  Figure  3.2. 

Included  in  the  appendix  are  job  control  statements 
used  to  invoke  the  NOPAL  Processor,  source  and  reformatted 
specification  listings,  cross  reference  reports,  and  the 
precedence  matrix  and  processing  sequence  of  each  test 
module. 
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STMT  NO. 


1 SPEC  MiNiPAoinsefi 

/•  TIST  MODULPS  •/ 

2 TEST  OC^INPUT;  /•  OC  INPUT  SHOPT  CHECK  •/ 

/•  NO  STIMUUI  •/ 

3 MPASUPCMCNn 

A CONJUNCTION!  <J2N.P,  J24.C>  • CONST^PINffES  OHNI 

A TAPCETt  MPESt 

S ASSEPTIOH!  MRES  > too  SOUPCP:  HPESI 

b lOCICt  I-  02.  *03! 

7 OUONDSIS  02:  1 1 NPUT.SHOPT t « AAI; 

S DIAGNOSIS  03!  (»  IPPESt  • OllNSMtOlS 

9 TEST  AM»t; 

10  MEAS: 

11  Asnr:  vt  • 0.2*  ^ o.06f 

U LOGIC:  *07,  |>»O0: 

13  DUG  071  PAPM«(VU  *VPMS*),  TYPE-  Ol 

Ih  OIAC  Ua:  AFfECTEO  Cn**P«  amPL.TOL  I STO.SPHE.FPEOI  • TYPE-  IE* 

lA  nTHPP  PAPM-  •AMPLM 

15  TEST  OISTO0T.2M) 

16  sri*«*. 

17  CUNj:  SANE  AS  OCV.ANSt 

te  MEASS 
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23  TEST  OISTOPT.VOLT; 

24  STIN  OCV.ANS: 
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25  JU  • StCNAL.AMC25.002NHZ,  ♦1309,  OC,  lKH2)t 

?6  PEAS; 

27  CONJi  <219,4,  CNO>  • SlNE,0IV2  VOLT,  •,  0 SECI 

27  TARGET:  V2; 

7P  ASSF  At : V2  >•  2.2; 

29  ASTT  42:  V?  <■  2.A; 

30  logic  *24,  tiS,  1-26; 

31  DUG  24:  TYPE-PlS,  TIME-0,  RESPONSE-?; 

32  OIAG  25:  PARHS-<V2,  ' VACM,  TYPE  - Ot 

>3  OIAG  26:  TYPE-PIT,  COMP»  REF.VOLTl AUOIO.lOHWl; 

J*.  TEST  FP6I?; 

STIn  OCV;  /•  27.5V  OC  TO  PIN  J24,ft  9/ 

COtiji  <J24,P.,  r,NO>  • CONST. SI27.5  VOLT  I: 

37  NE4S: 

’:M  COAIJ:  <J22,  GNP>  - SINC.OtVl  VOLT,  Fl  H2 , VAR  1 SECl 

3M  TARGET:  VI,  Fl; 

»n  ASRT:  if  V»RI  • no  then  Fl  ■ 9C6  *-  60 
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53 

53 

54 

HESS  <15: 
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MCSS  #61 

55 
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-ESS  *15 

5o 
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HESS  •!? 

5« 

YFSS  FIR 

/•  IMJT  1 

6V 

UUT.POINT 

6U 

UUT,»t  2: 

60 

61 

UUT.Pt 

62 

UJT.PT: 

62 

b3 

UUT.PT: 

64 

uut.pt: 

66 

•r.jT.PT: 

/•  UUT  1 

^Jio.A,  r.*«i>  • oiSTORrinNiPi  St  z rhzi 
TAFGCTs  PH 

aspt:  pi  <•  3; 
lOGIC:  9Z7,  l*•28t 

nur.  27:  PA4«METEPS«lPlf  'IMf  TVPE«Ot 
DUG  29 1 Cn«4PaniST0HT  lAUOIO.lOMUl*  TVPP««l8f 
PABHS^l*  lO'-W*  • I.OIt 

/•  Hf^SSCAE  DEFlNlTthNS  •/ 

HfSSACF  Ul  ALIAS«0ISLPAV,  TEXTaMTt  |P  M 

*•77  (IC  INPUT  SHOPTEO  J24-A/J24-C  •# 

•AVr.4C>t06  0EFKTIV6.  CHECK  PRINTOUTS  FOR  OEFCCTS.** 

*ppfss  STOP**; 

* IF  A 12  OIhuTF  mARMuP  is  OESIREO*  KEY  1*4  720t  * 

• niHERmSF « KFY  IN  60*  PRESS  YES**T 
•%C  OEFECTI V6, * * 

•0.0  MHZ  STn*  OUT  OF  IP  tolerance •*  I 
: 'MC  f.  kC  rONIROlS  TO  2 50000*  •• 

•adjust  AUUIO  GAIN  COTHROL  FOR  2.2  TO  2«8  VAC*» 
•(2*5  VAC  NafMNALI*  PRFSS  YES.*; 

: *10  MW  UrSTOpTtON  RCFERTNCE  VOLTTAGC  FAILEO**! 

: •iPt  AUDIO  OrSTORriON  GREATER  THAN  IP  2 PERCENT* • I 

conncctinc  points  •/ 

: J2/i  llMll^lvniT*  7Ut  0»  GNOIS 

J24.0,  alias  * XJ24.F*  CriNN£CTOR*(MilLT|Rif.,  SI, 
L(751T«(VQLT.  *15*  20,  GNOl  : 

J24.f.,  ALUS*>GNO.  CnNN»l7»ULT  IPLE,  Cl: 

Jt6.  COMNF.rTDR^cnAXIAL,  L I HIT  * (UVOI  T , 100.  0.  GNOI* 

• COAXIAI  CAftLE*: 
n<7.A.  LiHiTsivnir.  5.  o*  gno): 

JIO,l.  tlNlT^ivOlT.  70,  0,  GKOIJ 
ill.R*  At  tAS«^GNO: 


CO«»nNt**T 


C'IMP.FAIL  2 
f.Owp^PAli  3: 


ENf/l'AllUpcs  •/ 

IMPUT.SHM  T: 

STll.5»^»<Z.KpHJ,  FAILURE  FUNCTION*  FAEO.TOL, 

INDEX*  I,  PROTECTION  • It 
5T0.5HHZ.FRE0*  FAIE  FUNC  • AHPL.TOL,  INDEX  « 2« 

PPOTICT  « l; 

COHP  6:  AUDIO. lOMW*  FAIL  * REF.VOlT,  PROT*l,  •OISTORTION  REF  VOLT*t 
COHP.rt  7:  AllOIO.lOMW,  FAIL  • OISTORT,  PPOTECT  |0N*(  1 , 611 
COMP.H:  AUOIO.lw*  FAIL  FuMC*  OISTORtj 

/•  ATE  FUNCT  TONS  •/ 

FUNC  lot  CONST. S,  FilNCTfON  TYPE  *S,  PARN*  |.X  *$*  L INI  T*!  VOLT  , 60,01  • t 
VALUE  PCTUPNEO  ••  CONSTANT  VOiT**| 

FuNC  IO:  const. P,  TYPC*N,  PARAH*  I X,  ▼ , ( OHN,  tt)Or),  U * • V ILUP  •*  TRLIE /F  At  SE  * I 

fun:  301  SUJC.n.AI  t AS«SfNF.0FLAY,  TYPC*N,  PAHNl*  I X , T H VCHL  T , tO,  • 1C  | I , 

7akH7.>I  V,  n.  (H*4£,  I 0.01 1 • PARH2*(Z.S*SCCI,  •A‘*'*n.,  Fg£Q.,  Tl  HE  OELVD*  : 
^UNETtCf^  40:  DiSrCF.T  (ON,  IyPE*M*  PARN*  (X,T*x|,  /•  T OIST*  •/ 

PARN»(Y*5,(RMZ,100,0) » /•  FPlD*  */.  VALUE' • T RUE7 FALSC • : 

rJHCTKIN  50:  StlMAL.AR,*  M1a5>SAH,  TVPF«S,  «P(N5  « U 


It 

PA''’1>  IX  ,S,  («ll/ , 100,0.  1 1 1 , /»  IM  II'  Flic*'/ 

76 

PARM*?«  I Y,s,inp,-t0,-l50>  ),  /•  POWFR  •/ 

76 

PARM*3*  (Zi  St  rit  /•  MOOULATUJN  IN  "ERCFNT  •/ 

76 

PARM»6=  IW,  S,  (KMZflStO.in  /*  Mf)U  FREQ.  */ ; 

77 

FJNC 

no: 

FREO.TQLt  TVPE'F,  PAPM-COMPONENT; 

7B 

FUNC 

120: 

A“PL_TOLt  TYPt«Ft  PAP«»COMPO.NeNT : 

7S 

FJNC 

130: 

REF_V0UT,  TYPE-F  , PAR«*COMPnNENT; 

30 

FJNC 

UQ: 

OISTORT t TYPE*F,  P AR M»COMPnNEN T ; 

/• 

ATE 

INTFR-CONNFCTINC  POINTS  */ 

at 

AIE. 

POINT 

: ATE_J260,  UUT_PT=iJ2A_n ; 

f)2 


ENO  MlNlRAOtnSET; 


rais  PAGE  IS  BEST  QUALITY  PRACnCASIiE 
IBOJI  COPY  FURMISHEL  TO  HDC  ^ 


354 


eg 


if 

I 

I 

1 


f 


• « « • 


O O Q c 

Ul  tu  *«AJ  Ui 

^ ^ b* 

H 

< < < X 

Vil  O O O 

(/) 

2 r 2 

3 3 3 3 

2 

oc  « oe 

UJ 

^ ^ ^ ^ 

Z 

UJ 

w 

• • • • 

< 

O o o o 

2 2 2 2 

C C 3 O 

.J  ^ w 

ib 

O 

c c o o 
c O c c 

• 

^ b-  b-  b- 

o 

2 

Vt  uY  V»  bY 

< < < < 

C rf  cr 

UJ  Ui  (li  UJ 

ts  o o 

UJ  UJ  Ui  Uj 
►-  »-  b-  b- 
2 2 2 2 

V* 

^ V.  ^ 

II 

UI  Ui  UJ  u; 

T r r 2 

VY 

> 

< < < <« 

o 

2 2 2 2 

2 

< 

2 

• • * « 

2 

< 

• • « * 

CS 

UJ  UJ  UJ 

< 

X 

e:  e:  or 

3 

< 

u.  ^ u.  u. 

H- 

1 1 1 1 

u. 

2 

Ki  «SJ  fsj  PM 

C 

> 

I r X X 

r X s y 

• 

u>  in 

o 

i t 1 1 

2 

< 

O o O Q 

a 

1*  b-  b-  b* 

o 

V5  i/1  VI  i/> 

2 

• • • • 

O 

b-  ►-  b-  b- 

2 

X X X X 

O 

UJ  U.  UJ  UJ 

GC 

b-  ^ ^ 

D 

O 

ce  Of  a 
< < < < 

N 

O 

u;  UJ  Ui  UI 

Uj 

2 2 2 2 

I/' 

►- 

C£ 

< 

• • •»  ih 

o 

OL 

iV  b»  « 

cr 

u; 

^ •T  'C  >o 

Of 

2 

Ui 

UJ 

o 

C. 

b.  ^ b.  W 

< 

i/) 

z ^ z z 

(/) 

Ui 

Uj  UJ  UJ  Uj 

O 

s s.  X X 

lb 

< 

Utf  UJ  UJ  Uj 

o 

4/> 

>-  b-  b-  b- 

i/Y 

< < < < 

• 

UJ 

^ b-  b-  W 

3 

X 

V>  «/)  VY  V> 

2 

2 2 2 2 

••  •_  M 

# 

in 

2 

u 

« « « » 

M 

< 

O o o o 

W 

z z z z 

m 

%. 

M 

QL 

2 2 2 2 

b* 

& OC  01 

< 

OC 

< < < < 

b- 

« 

2X33 

VY 

\U 

« • « b 

♦ 

355 


THIS  PAGE  IS  BEST  QUALITY  PRACTICABLI 

fflUM  COPY  FUKNISUED  TODD, C 


CROSS  RffCRCNCE  MO  ATfRimifES  REPURf 


r«AMe 

DEE  NO* 

AtIRlBUrCS  ANO  RIEERENCFS 

• 1^ 

S6 

MESSAGE  lADEL 

31 

Bit 

5/ 

MESSAGE  lAREL 

33 

«t« 

SI* 

fACSSAGE  lAUCl 

22  SI 

• 4 

S3 

PI  $ SAGE  lAUEl 

«5 

5A 

HtSSAGE  lAeft 

Al 

ss 

MESSAGE  lARCl 
lA  A2 

ANPt. 

fC  S 1 L AOEI 

10  1? 

AMPL.fOl 

ftt 

ATr-IUNCI ION  ID.  E 

lA  GH 

AlC.J2Aft 

R| 

Atr  IMUNE  10 

AUOIO.iOMW 

A9 

10.  WMN  EA|iUR£«FUNCriONl 
13 

REE.Vm  T 

AUDIU.IOHU 

TO 

* CONPilNENI  ID.  WITH  EAliUAE-ElINC  riONt 

DISTORT 

AUUiri.2<< 

71 

^ 1 

CUMPUNENI  10.  WITH  FA1LURE-EHNCTIU9I 
22 

DISTORT 

Al 

?a 

ASSFRf ION  t AHFI 

A2 

29 

ASSLHilltN  lABCl 

CONS  I. R 

T3 

ArE*f=U9CTIUN  10.  M 

CUNSI.S 

72 

A 

Air-IUNCIION  ID.  s 

36  ?S  17  AS 

0 

S2 

NESSAG&  lAftEl 

a 13  32  A}  SO 

OC.INPUI 

2 

TEST  lAOri 

3 6 

OCV 

IS 

STiPUl.HS  1 AAEL 

36  2S 

OCV.AMS 

24 

STIMULUS  LABEl 

25  1/  AS 

OISLPAV 

5? 

SYNONYM  OF  message  LABEl t 0 

OiSTURT 

no 

ATE'FUNCriUN  ID.  F 

SI  TO  71 

OISIURf.VOLl 

23 

TEST  lABEl 

2A  26  30 

DISTUPf.lOMM 

AA 

TEST  LABEl 

AS  A6  AO 

0ISIQRf.2U 

IS 

TEST  1 Alin 

16  IP  21 

OISrORTfON 

75 

ATE-EUNCTIHN  10.  M 

10  A 7 

02 

7 

OlAGNirSJS  LABEL 

6 

03 

0 

DIAGNOSIS  LABCL 

6 

OA 

Al 

OIAGNOSIS  lAHEl 

AO 

03 

A2 

DIAGNOSIS  LABEL 

AO 

»!•  rAO  IS  Btsi  aijAMn 

jgffi  OOiPX  FUtttUSHBD  10  DDC  ^ 


356 


I 


I 

r 

i 


U6 

43 

Of  A|, MUSIS  1 Afll  1 

41) 

tw 

l> 

OIAUNUSIS  LAilM 

12 

as 

14 

VI AGNOSI S 1 AHf 1 

13 

34 

i&Sl  LASEt 

37  40 

i «£')_  HiL 

< r 

All -fUMLl lUM  iU.  F 

43  61 

fl 

VAHMSig  IU 

41 

C*No 

T.S 

SYNONYM  OF  UM1  I'OINI  lOt  J24  .C*  J|9.0 

19  2 1 3*  30  4V  69  60  62  63  64  2b 

inpui.snokf 

CONPONCIVI  1 0 

7 

001  pOINI  in 

17  46 

J16 

fc? 

JIS.A 

<.-3 

OOl-POlNl  111 
it  4 7 

6'> 

OOf-POlNl  10 

J 19.1 

64 

OO1-P0INI  in 

19 

JIZ 

4V 

VWT'fUJNI  II) 

3S 

60 

IJtll-POIM  It) 

4 36  HI  2b  17  45 

J?^_C 

61 

OOl-POINI  lU 

HlNlKAOIOSt  r 

1 

SPi  r u ICAT  1 ON  L ABFI 

12 

'IKtS 

4 

VAklAiUL  10 

6 a 

PI 

1*> 

VAklASlF  ID 

20  50 

p 1 

47 

VADIAftll  10 

4S  50 

MtP.VOLf 

79 

AIF-IONCfiON  1D«  ¥ 
u 09 

SAM 

76 

SYliOtlVM  or  ATE-FUNCTION  10:  SIGNAl.AAlf  S 

SICMAl.AH 

76 

All  -FIKACI  ION  |0i  S 

35'  17  45 

S iNt.O 

74 

A 1 1 -f UNCI  ION  lOt  M 

2 1 38 

SlNE.Ufcl  AY 

74 

synonym  Of  ATF-FIJNCTION  10:  SINEAD,  M 

SH)_S“HZ_FPE 

t7 

roMPONior  10,  wim  faiiuhf-functimn:  FRio.ini 

42 

SIU.l»MM/.f  HE 

6fl 

COMPONfcNI  10,  WlIH  FAllliHE-rtiNCnON:  AMPL.IOL 

vakI 

41 

VAHIASil  10 

IH  39 

VI 

)H 

VARIAPLE  10,  (UOBAL 

n n 

V? 

27 

VARlAIUf  ID 

28  29  32 

XJ2^.h 

60 

SYNONYM  OF  UOI -POINT  II):  J24.R 

1 

66 

COHPONFNT/FAILUHF  SEQH 

67  68  69  70 

67 

COMPONENT/FAIIUHE  SEQP 

2S 

31 

DIAGNOSIS  IABEL_ 

30 

25 

32 

DIAGNOSIS  LABEL 

30 

26 

33 

UIACNOSIS  LAHtI 

30 

27 

SO 

DIAGNOSIS  LABEL 

21 

28 

51 

DIAGNOSIS  LABEL 

ifQ 

3 

60 

COMPONENT/EAILURE  SEOH 

30 

2? 

diagnosis  label 

21 

6 

69 

tONPONENT/FAILURE  SEQ# 

70 

7 

70 

COMPONENT/FAl  lure  SEOl^ 

ERROB/WARNINC  messages  GENERATEO  nORINC  CROSS-RCEEREMCE: 

•STATISTICS*  NO.  Of  XHEFl  ERRORS  » 0 NO.  OF  WARNINGS  ■ 0 


357 


rais  WGS  Ts  BEST  QUALITY  FS/^mmO. 
roCrtl  COi-Y  f UivjjJSiigj)  TOBDQ  


/•  REFORMATTED  SPECIFICATION  REPORT,  FILE:  SOURCF2  •/ 


/•«•.*•••*«*•««**•*•***«•**•***«•«*«*•*«*•«««•«««/ 
/•  •/ 

/•  NOPAL  TEST  SPECIFICATION  FOR  MINIRAOIOSET  */ 

/*  */ 

NOPAL  SPECIFICATION  MINIRAOIOSET; 

/«•«*«  •*««*••««*«««**••«** 

/«  *t 

/♦  TEST  MODULES:  6 ♦/ 

/*  */ 


TEST  OC_INPUT; 


/•  NULL  STIMUL I •/ 

measurement  tM_OC_INPUT(OC_INPUT I; 

conjunction  iM_H0001 1 $M_DC_ INPUT): 

I<J2<>_B,  J2A_C>  s CONST_R  IMRES  OHM  )) 
TARGET:  MRES; 

ASSERTION  tM_W0002IiM_0C_ INPUT ); 

MRES  > 100 

SOURCE:  MRES; 

LOGIC  $LQGtCOOlOIOC_tNPUT) ; 1-02,  *03; 

DIAGNOSIS  02: 

OPERATOR  MESSAGE: 

AFFECTED  COMPONENTS* INPUT. SHOR T, 
TYPE»«A; 

DIAGNOSIS  03: 

OPERATOR  MESSAGE: 

other  PARAMETERS=tMRES,  • OHMS*), 
TYPE*n; 

TEST  ampl; 

/*  NULL  STIMULI  •/ 

MEASUREMENT  tM.AMPLI AMPL) ; 

ASSERTION  tM_wOOOl (SM.AMPL ): 

VI  = 0.26  ♦-  0.06 

SOURCE:  VI ; 

LOGIC  SLOGICOOIOIAMPL) : «07,  1-08; 

DIAGNOSIS  07: 

OPERATOR  MESSAGE: 

OTHER  PARAMETERS*! VI,  ‘VRMS'), 
TYPE=0; 

DIAGNOSIS  OR: 


n,SFABIS>«W;“*" 


OPEdArOR  MESSAGE; 

AFFECTED  COMPONENTS»AMPL..TaL ( S T D_5HHZ _FR F I , 

OTHER  PARAMETCRS*( 'AMPL • I , 

TYPE=i»6; 

TEST  OISinRT_2w; 

STIMULI  t S_DI STORT_21DI STOHT_2W) ; 

CONJUNCT  lOM  $S_*<0001  ( tS_D  I STOR  T_2)  : 

I<J2A_0,  GNO>  * CnNST_S(27.5  VOLT  I)  t 

(<J16>  = S ir.NAL_AM(  25. 002  MHZ  ,«-n  00  .0  3?  ,1  KHZ  )> 

MEASUREMENT  SM_DISTORT_2(OrSTORT_2WI  ; 

CONJUNCT  [ON  tM_W000l(  TM_n  ISTCIR  T_2)  : 

KJl9_Li  CND>  = DISTORT  lONIPl  S ,l  KHZ  )) 
target:  pi; 

ASSERTION  $M_W0002UM_0IST0RT_2); 

PI  <»  5 

SOURCE:  Pi; 

LOGIC  5L0GIC0010(0rST0RT_2WI ; *27,  1-30; 

DIAGNOSIS  27; 

UPFRATO*  "ESSACE; 

ITHFR  PARAMETERS'IPI.  ‘X*!, 

r < •*  *0 : 


■ s 13  10! 

Ai  ' »•  -f  A.VA  : 


■ * 


• AffOri.ZRl  . 

•«  . • 'a*  , A.  9», 


BBIS  page  is  best  QtJAlitTy  PRACWySifiS 

mOH  CSOPY  FURWISHEID  10  DD,Q  — 


TIME-  0. OOOOOt»OOSEC , 

RESPONSE’?; 

DUONGS  IS  25: 

OPERATOR  MESSAGE: 

other  PARAMETERS=IV2,  • VAC), 

TYPE’O; 

DIAGNOSIS  26: 

OPERATOR  MESSAGE: 

affected  COMPONENTS»PEF_VOL T( AUOIO.IOmw) , 
TYPE’Al?  ; 


TEST  FREQ; 

STIMULI  OCVIFREO); 

CONJUNCTION  $S_W000lIDCV ): 

(<J2A_8,  GNO>  = C0NST_S(27.5  VCLT  II; 

MEASUREMENT  tN.FREQI FRED  I ; 

-CONJUNCTION  $M_W00011  t>\.FRE(JI  : 

I<J22,  GNO>  = SINE.DIVl  VOLT  ,F1  HZ  , VAR  I SEC  II 
TARGET:  FI,  VI 
SOURCE:  VARl; 

ASSERTION  tH_w0002 I JM_FRE0) : 

IF  VAR  1=50  THEN 

FI  = 5E<-06  »-  60 

ELSE 

FI  = 5£»06  ♦-  2.5 

SOURCE:  VARl,  FI; 

LOGIC  SLOCICOOIOIFREQI  : ‘OA,  I -,05 , *06; 

OIACMOSIS  Oa: 

OPERATOR  MESSAGE: 

TYPE’AS. 

Tint’  O.OnoOOE’OOSEC. 

• » »Omst  ••  VAR  1 1 ; 


.ATI 

FPri, 


Z«ZS  PAOE  IS  5PS7  QUALITY  FRAOyiCABIfl 
UdM  COPT  FURNISHED  TO  DDC  ^ 


CONJimcTIOM  fM^woOOU  »H.OISTOftT  u: 

KJ19.A,  ONO>  • UlSrnATfUNl^l  t ,2  KH{  )| 

fAgceri  Pi; 

ASSERTION  l^^_w0002  I »h_DIST09T«1  I « 

«»l  <-  S 

snuRCF:  Pi; 

LHCIC  iincicaoioioi STOft T.IONUI X *27*  1-281 

/•••  FCi.LQwlNC.  DIAGNOSIS  ALR.EAOV  OCFINEO  aEFQHEl 

OlACNOSIS  27: 

OPEAArOR  MfSSACE: 

OTHEA  PA8AHETFaS«(Pl»  MM* 

TYP6-01 


j 

) 

i 

I 

i 


•••/ 


T UUGNOSIS  28: 

OPERATOR  HESSAGE: 

affected  Cn.HPONENrS*OI  STORTIAUOIO.lONWlf 
other  PARANFTERS-I  • tOMW*»  L.OIf 
TYPE*# 18  ; 


/•  •/ 

/•  HESSASES  •/ 

/•  •/ 


NESSACE  4A; 

rexT*‘P/T  DC  INPUT  SHORTED  J2<>-n/J29-C  •,  *AN/CAC-106  OEFECTtVS.  CHECK  P 
RINTOUTS  FOR  DEFECTS. •*  ‘PRESS  STOP.*; 

MESSAGE  0:  AL f AS«OrSLPAr, 

TEXT-'iT;  tP  •; 

MESSAGE  #6: 

TEXT«*SC  DEFECTIVE.**  *5.0  MHZ  STD.  OUT  QE  Sp  TOtERANCE.'; 

MESSAGE  #18: 

T£xr**|Al  Auoro  DISTORTION  GREATER  THAN  SP2  PERCENT.*! 

MESSAGE  #15: 

TEXT**MC  C KC  CONTROLS  TO  250000.**  'ADJUST  AUOlO  GAIN  CONTROL  FOR  2.2  TO 
2.8  VAC‘«  '(2.5  VAC  NOHINALI.  PRESS  YES.*X 

MESSAGE  «17: 

TEXTs'tO  NW  DISTORTION  REFERENCE  VOLTTACE  FAILED.*! 

MESSAGE  «5: 

IEX1**IF  A 12  MINUTE  WARMUP  IS  DESIRED*  KEY  IN  720!**  * OTHERWISE*  RET  IN 
60.  PRESS  YES.*; 




/•  •/ 

/•  UUT  COMFOHENTS/FAliuPES  •/ 

/•  •/ 




LpMp^FAli  li  |NP«ir.SN«NiT  t 

(•M  fftli  If  tfO.AMl.PSff*  ffAltUil  »WaiCTtQlt«P«ff«.rOi  • INOfl*!,  PtOTHTallfir 
tf*#  ti  !»•  AAtl.fAf  I'M*  .TOE  • (•^fl*!*  P«QfKT«||M 

f m0  • W6M  •«««  AAtk  .At  MH  • • PR##f<T*«|| 

6*  » *^*  •«*  •••  *^f* 

.•  ^ t 99  t '^9  ' »tm  9 »••••<  #•»  ! . *1 


UUT.POlNr  2s  J2«.B|  ALIAS*X42^.Sf  CONNECTOR- t NULT IPtCt  ilf 
lINIT-UncTf  3.SOOOO€»Oli  2.0OO0OE»Olt  CNOIf 

UUT.POINT  • J24*.C,  ALIAS«CN0«  CONNECTQP-f  MULT  IPLEi  CM. 

UUT. POINT  I JM.L*  LIH|T«IVflLTt  T.OOOOOE^Ol*  0*000006*00#  GNOM 

UUT.POINr  I J16.  CONNECTHP-ICOAXI Alt  I# 

LlN|r»(UVnLT»  l.00000E*02,  0*00OOOE*00»  CNOM 

COMMENTS-*  COAXIAL  CABLE* S 

UUT.POINT  I JlO.A*  LlP4IT«IVnLT,  S*00000E*00»  O.OOOQOE*00#  GNOM 

UUr.POINT  I J22«  LIMir<|vnLT»  7.00000E*0l»  0.000006*00#  GNOM 

uur. POINT  : JIO.A,  Al  lAS-CMOS 


/•  •/ 

/•  ATE  FUNCTIONS  */ 

/•  •/ 


FUNCTION  203  CONST. ft,  FUNCTION  TVP6-M,  JPfNS-  2, 

PAftAM_Ol-(X,  T,  LINIT-IOHM,  1.000006*0},  1.000006*001 1 • 

VALUE  ftEruBNEO-*TftUF/FALSE*S 

Tunc T ION  ' 120;  ampl.iol,  function  type«f, 

PAftAN.Ol-lCOMPONENT,  SM 

function  <*0i  DISTORTION,  FUNCTION  TYPEV<,  iPINS-  2, 

PARAM.OI-IX,  T,  L|M1T«I<,  1,000006*75,  •! .DOOOOE*?} M • 

PAftAM.02-IY,  S,  LtMiT-IXHZ,  1.000006*02,  0.000006*001), 

value  PETURNE0-*TPU6/FALS6*: 

Function  mo:  distort,  function  type-f, 

PAPtM.Ol-iCnMPONENT,  s): 

Function  5o:  signal. am,  ALtA$«s>u4,  function  tvpe-s,  ppins-  t, 
PAftAN.Ol«IX,  S,  LINIT<>INH7,  1.000006*02,  1.000006-01)1, 

PAp<AN.02>tY,  S,  LlMlTsliitf,  >1.000006*01,  -1.500006  *02 )) , 
PARAM.0)«(7,  S.  LIMtr«l',  I .000006*75,  -t .000006*75) ) , 
PANAM.05*U,  S,  LIN|T,|K|i2,  1.500006*01,  I .000006-0  1 1 M 


60NCT10N  30:  SINe.O,  AL I AS-S INE.OeLAY#  FUNCTION  TYPC^M#  ¥PINS*  2# 
PARAM_Ol»{X,  r,  L5MIT*(V0LT#  l.OOOOOE^Ol,  - I .OOOOOE  + Ol I) , 
PAkAM_02=( V,  T,  L IM| T=tMH^  , I .OOOnOELOI , O.OOOOOEfOO) I , 
PAPAM_03  = 12,  S,  L1M1T=(SEC,  l.00000f*75,  - I . OOOOOE a 75 ) 1 # 
COMHfNTS=' ApMPL. , FREO. , TIME  0£LY0«; 

function  130:  WEF.VOtr,  FUNCTION  fYPE=F, 

PAMAH_Ol - I component , S I : 


FUNCTUIN  10;  CONSI.S,  FUNCTION  TYPB^S,  PPINS-  2# 

PARAM_Ol  =|X,  S,  LI  MI T-IVDUT,  6.00000E*01,  0.000006*00  I I • 

VAliiF  KLTURNFD-*  CONSIAN!  VOL  I . • ; 

FUNCTICN  IIO:  ifteO.IOli  FUNCTION  TYPE»F, 
pARAM.oi  * irom»t>NfN  T , S)  ; 


/•  •/ 

/•  Aik  CONNtCIION  POINTS  •/ 

/•  •/ 

* 


• f#  .'^INT 
I ^ . I e r 


• t » i/  , 


)Nft  Pol  Nt  , I i/%  . •!  I 


C p 


0 


SJHMAHY  C»OSS-REFERENCESf  FILE;  XREF2  AFFECT El)-COHPON ENTS  <»>  DIAGNOSES  <*>  TESTS 


«/»  I ►-at 

uj  I ^ X 

•J  I o o ac 

3 1 > — CM 

0 I ►-  III 

C I 3 h*  ►-  w 

X I a.  « X « 

II?  c c c 

w-  I — O u ^ 

1/9  I I uj  ^ s/1  </9 

01  I U « X — — 

^ I o u,  < a e o 


I rsi  tr-  or  c OP  O 
I o Q o 


ac  oc  — a 

a.  2 <M 

I IX  X I 

O X c 

X r — o — 

►-  I XX  I — Q 

? I sT  O 13 

u;  I I I — O < 
? I « O O ^ — 
C I *-*--30^ 

a I ^ I/T  s/I  < a gr 

X I 5 — — • < r 

U I ^/l  o U •/  »- 

it  C X — 

I ^ I I > 3 a 

SM  I p O ^ I — 

» I C SM  X ^ •• 

W I X 4 T * *i 

«*»  I — ^ ^ a 

I «* 

^ t - ••  ' 

« . ^ • 


IS  best  QUAMTyFRACn<S4&S 

0QP2f  ^URSISHES)  IPJI^ 


z 

1 

o 

o 

SA 

SJ 

z 

1 

*• 

3 

u/ 

X 

u 

O 

< 

sil 

z 

o 

1 

A 

z 

H 

o 

<sg 

«• 

GC 

V 

sj 

n 

s/9 

C 

1 

s/> 

kU 

Ul 

s/9 

3 

1/9 

U/ 

U/ 

T 

•— 

< 

< 

O 

o 

3 

O 

O 

1 

m 

n 

O 

X 

X 

cc 

S/9 

1 

1 

a 

►- 

3 

(/I 

s/9 

s/9 

fU 

SiJ 

x 

• 

UJ 

M 

1 

►- 

w 

o 

• s/9 

X 

A 

A 

• 

c 

11 

• 

o 

S/>  L- 

II 

A ** 

V 

> 

— ^ 

V 

X S/I 

s/) 

s/> 

1 

o o 

— — w 

s/> 

kU  > 

S/9 

3 3 

o 

x * 

ee  1 

z 

X 

z 

o — 

k^  ►- 

c 

O 1 

• 

O 

►-  X — 

a 

— « ^ 

^ «• 

o 

> 

S/I  — * . r 

• C 

lac 

X SA 

c o 

1/9  s/9 

3 o 


I A •-.  7 ^ 

W s/9  e X s/>  wr9  X 

Of  W o — — X 

C 3 - — 3 5 O 

►-  X — I ^ 

S/I  O X w I I I 

^ ^ ee  ^ ►-  ^ 

O 1 X O OC  Ob  oc 

^ rg  ^ Q c O 

► CC  I s/9  ►-  ►-  ^ 

C H-  — s/9  s/9  s/9 

s/9  H-  C — •-  — 

^ </9  c o a o 

o ^ • 

11/  Q s/t  — • • • 

Ct  — 

IL  *0  — ‘/Is/*.  s/is/ix 
*s/9  •UJ>-XX>**3^- 

— — — c^-jX— -js  ^ 
XXXsi.CO.XCOC 
— -fg—  > •^  fst  > > 

^ • I I I I I I 

3h- 

ZC?  — C3CCCO 

I */l  I UJ  S/*  s/9  A/9  1/9  W9 
SJ  — SJOC  — — — — — — 

occsi.caoooo 


k.  O X 
-i  T 
o • o 
> — — 
IX  I 

ec  X cc 
C X o 

►-  o »- 

s/9  S/I 

c ►-  c 

ec 

• c • 


sox 

fg  /sj 
I • I 
-«►--»»- 
X a X (X 
'-0—0 
c »-  O V- 

u«  s/9  Ui  </i 
oc  •"  a — 
ku  O u.  o 


•-0*-*- 

oe^-Ol» 

O S/I  uj  — i 

^ « o 

s/)  O u.  > 

— I - I 

XI  o • •»- 

I — — « 

S/I  I *1/1X0 

s/9  1 X ^ ^ S/9 

XU  \ — — -J  -i  — 

•J  I X 3 O C O 

3 I SM  > > 

oik-  I I I • 

0 I 3 I-  k-  — 

X I CL  oe  a s/I 

1 I z c o c — 

k-  I — k-  k-  I-  o 

T/9  I i S/l  s/9  I/I  LU 
Sbi  I o ^ — X 

^ I O O O o u. 


• su 
X X c 
< I 
• su 
X z ^ z s/9 
O 1 — 

• •-  < 1/9  • 

« ^ I % T/9 
IX  w O I 
^ O X 
^ Z VM 
Z s/9  O Z Z 
3 — — - 3 
O O s^  s^  O 


# • ► » 


W X 


e.  oc 

VI 

z ►- 

UJ 

— < 

1 z 

u 

oc 

z 

o > 

o 

o 

u 

VJ 

Z 

VO 

o z 

Oi 

lU 

3 

u> 

2 u; 

c 

UJ 

u 

«/» 

M 

V* 

— U 

z 

a. 

z 

c 

£ 

►- 

c 

^ < 

o o o o 

M 

> 

D 

z 

< 

2L 

Z 

Z “>  i/\  1 

1 

l/> 

-7 

o 

O 

u.  C 

o o o c 

kA 

z 

< 

(K 

wo 

< 

X < 1 

1 

\Xi 

o 

< 

VO 

mm 

o 

o o o o o 

u 

u 

a 

> 

< 

a 

uj  uj  I C 

1/>X  OOOOW  ac 


MDOUlf  StUUrNCl»«C  AHPl 

ANAiVSIS  OF  me  AOJACfNCY  MATRIX 


THIS  PAG!E  IS  BSST  QUAI/tlY 

raOM  CXiPY  FURNISHED  10  DD,0  ^ 


^ • 


& a. 
* > 
c ^ 


5 

- c 

> «/t 


A t<* 


a 

> o 


0 

1 


w m 

1 ♦ o 


Z 

O Z 

U X - 

z • 

o ^ • 

o c 

A • a M 

e ii>  X 

X A‘  o U1 

c ->  3 a. 

X > 

• < a ^ 

C I \U 


c 

V — 

•»  t/t 


e •• 

X •• 

u a. 


< ^ 


•• 

lU 

0j  n w 

^ >/  af 

U O 

c - c 


o c o o 
O O O o 


r »/) !.« 

a oi  M (k 

;if  s 

1*1  c o — 
<1^  < < s 
«,!*  — «« 
< o o > 


o 

S t 


o u o 

« «w  Z 

e > — 


z 

s > 

o < 
z “t  ^ 
XU  C 


g = 

C ♦Z' 
X — 


< 
z z 
— < 


o — a o o c 
o c 3 c c o 
ooooe— 
coooo— 
M o a s o o 
e o o o e o 


r z 

o c» 

» » Z sa 
^ Z UJ  iu  UJ 
OW»“<A*A  — 

z z ^ c o « 

5 3 * z z < 

-)  n C M 

z z «A  < < a 

a c */»  — — < 

u u < s 3 > 


fM 

c c o 
coo 
o a o 

s . 


I I I 


••  1^  ^ ^ . 


— > z 


« o 

UJ  ^ - 

O \J 

tc  Uii 

o > 

« «< 
^ tw  • 
O U O 
X IM  Z 

o > — 


1 1 #> 


OUCNOSES  OTHER  P«RAMETER$«I  • t* . Plii  TYPE 


INTftA  MODULE  SEQUENCING  OISTORT.VOIT 


IS  BteTaiJU®*  *’*****• 
roog  COPY  FUIttllSHESJ  iow?Q  — ^ 


V 

» 

^ *>4 

UJ 

z‘ 

u 

«i»  7 

iA 

o> 

UJ 

5^, 

2 

•^1 

A 

O 

k 

A 

fr 

O; 

o 

lA 

•« 

• 

Of 

O 

# 

^ M 

a 

«» 

o 

> e. 

«« 

p» 

» 

» 

o 

mJ 

p 

• « 

o 

O 

> 

r»  o 

♦ 

> 

M 

Ui 

1 

M 

«•  m 

o 

> 

tA 

o 

UJ. 

1 ♦ 

o 

« 

O 

!•  * 

o 

1 

o 

p 

UJ 

2 ^ 

• 

z 

O X 

o 

A 

w 

u r 

lA 

p 

z 

P (M 

UJ 

UJ 

H 

o 

z 

z 

o 

MM 

o 

A • 

»» 

a. 

A 

o tr 

z 

O •• 

»• 

2 ~ 

* 

o 

2AJ 

fM 

<M 

O ^ 

iA 

u 

O > 

> 

> 

T 

AJ 

e 

* < 

o 

m 

• 

• 

* 

UI 

< *• 

^J  •• 

fM  •• 

1.^ 

■ 

IM- 

UJ 

UJ 

u 

9 Ui 

N U 

P LJ 

Ui 

a 

UI 

— o 

Ok 

< 

(J 

A flC 

3 

V5 

V ^ 

> 

u. 

V < 

o 

<s  C 

<M  O 

«» «/) 

< 

> A 

> A 

0*^000000 

OOOOOCOO 

OOOOOOO.^ 

oooooooo 

OOOOOOO^ 

ooooco^** 

INOOOOOOO 

00900000 


B 

i 

tA 

A 

mm 

2 

2 

UJ 

Ui 

UJ 

C 

O 

U 

<A 

u 

Mi 

M 

z 

c 

c 

z 

d 

N> 

o 

z 

z 

3 

< 

oe 

Ok 

-> 

o 

o 

MM 

UJ 

UJ 

z 

< 

< 

2 

ee 

A 

A 

c 

M 

M 

C 

< 

A 

A 

u 

o 

o 

Sil 

> 

< 

« 

2 2 

w 

O 

o 

O O 

2 

O 

o 

2 3 T/»  i/j  lA 

UJ 

UJ 

O 

o 

^^OOUJUJUjUJ 

3 

z 

2 

X 

O 

< 

1 

1 

rz^-H-ooo® 

UJ 

2 

A 

A 

z 

30araZZz< 

A 

A 

AJ 

AJ 

RA 

^^uiujOOO«« 


O o o •m 


o o 

B S 

I I 

^ \ ^ ^ ^ ^ ^ 


Ui  »»  «i« 

O \J 


S3g“'  ^ * 

S%f 


DIAGNOSES  OTHER  PARAMETERS- ( • VACS  V2I,  TVPE 


PA®  IS  BEST 

oogx  soxgQ  - 


^ A — a & 
a - r > 

a o ^ 


e^eoooooo 

o-*ooooooo 

eoo  — OC3CO 

caocoeo*«o 

ocooooooo 

ooccoccoa 

OOOOOO^’^O 

<v00000-*00 

oecoooooo 


L z «/i 

rN-cccsxr 
■»vuc<JO  — — — 

^^soc>»> 


z o o o 


« o 

S4I  ^ ^ 

a u 


« a ^ 


368 


INTHA  MODULE  SCOUENCINC  0 1 STOR  I_  lOM 


IHIS  PAGE  IS  BEST  QUALITY 
P350M  COPY  FUKNJSHEO  10  DD.C  


n -• 

• 

V 

KJ 

3 

t-j  z 

T 

O 

X 

•• 

a 

1 

• 

o 

CM 

M 

* 

c 

UJ 

o 

D 

& 

> o 

> 

• 

«u 

iTk 

w 

0. 

• i' 

a 

r-  O 

c •• 

2 

• 

CM 

►“  « 

•«  m 

lA 

M 

U1 

»>  % 

a 

1 * 

C 

QC 

» 

II 

C 

»/» 

It 

• 

Z fSJ 

UJ 

LA 

O X 

LA  -. 

* 

O X 

►-  > 

c 

2 >- 

M 

II  PM 

UJ 

II 

A 

X 

e 

2 

or 

c 

O • 

LJJ 

w> 

A t 

a. 

A 

3 

C »A 

r c 

c •• 

•• 

U.’ 

Z 

r iM 

o • 

2 — 

1C 

O 

e — 

u; 

o a 

O. 

< 

r 

or 

1 

• < 

c * 

• » 

< 

w 

£ 1 

UJ  • 

< •• 

r>  •• 

cu 

O' 

1 ^ 

^ 2 

1 h- 

UJ 

O 

^ < 

u;  y 

9 Uj 

It  LJ 

ac- 

CM  Z 

UJ  o 

V C£ 

LU 

«/i 

UL 

n a 

u 

O 

3 

•> 

V — 

’.fe 

V < 

c 

•4  O 

c 

~ «/i 

< • 

a LA 

O 

s 

z 

z 

s 

o 

c 

bL 

LA 

w 

2 

vc. 

►- 

u_ 

UJ 

c 

u. 

o 

o 

o 

c 

Lj 

UJ 

a 

LA 

o 

«J 

A 

z 

& 

z 

c 

►- 

o 

o 

o 

o 

o 

>• 

75 

2 

3 

oc 

z 

<A 

o 

“> 

UJ 

o 

o 

c 

c 

c 

o 

•u 

A 

z 

< 

2 

tt. 

•A 

< 

UJ 

c 

c 

< 

LA 

o 

o 

o 

o 

c 

«4 

o 

u 

o 

u 

> 

< 

c 

CM 

c 

o 

c 

o 

o 

ae 

c ^ - C o o 


r z 
c o 

^ ^ O vju  UJ  UJ 

o UJ  -J 

z e *-  c o « 

r r ar  z 2 

n-»L*:oC  — 

2 Z w*.  < < of 

o a V.  — — < 

O < C C > 


— r<j 

o o o 

O O 
O O 

s s 

I t t 

X 

^ ^ •'J  r\i  ^ 


--  <S  ^ tf  - ^ 


uj 

w O 

z o 

ui  UJ  c 

=>  z 3 

e < I 


CM 

o 

o 

e 

3C 

- ^ 

a «• 


PM  r% 


CM  o 'T 


CM  ■ , 
• ui  *0 
--  O CM  UJ 

» u.  oc  a «/•  ' 

ft-  UJ  3 UJ  w < 

^ or  O a:  2 I 

u'  X «✓»  X — I 

r I 3 z 2. 

o o o a c ' 

a 0^  a:  QC 


C O o n Q ' 

UJ  UJ  UJ  UJ  UJ  * 

2 2 Z Z 2 

o:  OC  Q£  O'  < 

D D 7)  O -3 

h-  ^ h-  ^ ^ I 

oi  UJ  UJ  UJ  u.  I 

tf  tf  or  ou  af  • 


369 


